Determine whether we are painting ourselves into a corner with current Xmeta behavior

Taken together, I think that the presence of #36, #48, #49, #65, and #68 (closed) mean that we should carefully think about the future of Xmeta handling before we declare 1.0 to be stable. We don't need to have Xmeta in its final form when we go stable, but we do want to make sure that the default behavior of Xmeta is basically reasonable, and that we'll be able to extend it as we like.

(I want to avoid a situation where "everybody knows" that ${Xmeta(foo)} is a footgun, and that you're always supposed to use ${Xmeta(foo) except sensibly} instead.)

I don't have a great sense of how to do this analysis, unfortunately.

One approach we could take would be:

• Look at the full range of what can be put into attributes and handled with proc-macros. IIUC this is very broad.
• Consider how much of this syntax we can actually handle today: how much we can consume, inspect, and expose.
• Of the syntax that we can't handle, consider whether our current behaviors (as applied to that syntax) make sense.

Another approach:

• Come up with one or two candidate solutions for each of the tickets above.
• Make sure that the proposed syntax extensions for those tickets are "nice". (IOW, do they make us wish that our current Xmeta expansions/conditions acted differently?)

This is nebulous so we can probably declare it closed once we've thought about it for a while.