Looks reasonable to me, as long as the analogy to CommonMark’s “indirect” link syntax is also taken into account:
Simple extension of indirect link syntax :[here][ref] in _CommonMark_ text
[ref]: http://example.com/text.md "Example text to include"
But where does the here and Example text to include text strings go, when after all the string :[here][ref] is supposed to be replaced with the “transcluded” text? They would just be discarded and have no purpose, right?
So a symbolic reference or an in-line URL would be enough, either written as :[ref][] (with the same “fall-back” property), or as:
Simple analogy to indirect link syntax :[ref] in _CommonMark_ text.
Analogy to direct link syntax :(http://example.com/text.md) in _CommonMark_ text.
[ref]: http://example.com/text.md
Now the first case looks suspiciously close in intent, syntax, and behaviour to
Existing syntax: &ref; in _CommonMark_ text (via *entity reference*).
while the second case (the inline URL) looks pretty ugly and error-prone to me.
And why shouldn’t we be honest and admit at this point that we re-invent external entities in CommonMark— the exact same thing that in XML would be done by placing
<!ENTITY ref SYSTEM "http://example.com/text.xml">
in the internal subset and then referencing (“transcluding”) this text with literally the same syntax &ref; as given in the example above?
And since we have re-invented external entities already, why not re-invent internal entities, too? Which could look in CommonMark like this:
Simple extension: insert &here; some internal entity.
[here]: "at this point"
Maybe it seems too far a step to use &ref; for these tricks too, and it may seem that :[ref] would indicate clearer that “something special” is going on here. But the flexibility and consistency that using &ref; in these cases too would entail—adopted directly from XML—is worth considering, I would think. (And note that this does in fact nothing else but replicate the purpose and use of external and internal XML entities in CommonMark.)