What differentiates the specification’s example 304 code span
`⎵``⎵`
from cases like
"`⎵X⎵`"
is the fact that in example 304 the “leading” and “trailing” SPACE is only there for syntactic reasons, and strictly speaking both SPACE characters are part of the “opening delimiter” ( GRAVE ACCENT , SPACE ) respectively the “closing delimiter” ( SPACE , GRAVE ACCENT ) of the code span: removing one of these SPACE characters disturbs and disrupts parsing of the whole code span.
When there are no GRAVE ACCENT characters (aka “backtick”) adjacent to the code span delimiter, as in the second example with the enclosed “X”, one can obviously add and remove SPACE adjacent to the GRAVE ACCENT without any consequences for parsing.
In this light, it only makes sense to discard SPACE characters in the situation of example 304 (where they were inserted for purely syntactical reasons in the first place!), but not in the second example, IMO.
A rule concerning leading and trailing SPACE in code spans based on this difference could be:
Any SPACE after the opening “backtick” character(s) and before the first “inner backtick” character (if there is one, that is, not one of the closing “backtick” characters) is discarded; and vice versa any SPACE in front of the closing “backtick” character(s) which follows the last “inner backtick” character.
However, I have the feeling that this could (and should!) be said in a much cleaner, simpler way, maybe just using a grammar of sorts?
[ Edit: I have posted a proposed modification of the CommonMark specification over there. ]