I think this is a good idea, and while I think it could be an independent proposal, I'm fine with rolling it into this one.
In all of our discussions about #if, it's been brought up that there is value in parsing the untaken if's when possible (e.g., for tools). Some new features on that list (existential any, regex literals, @preconcurrency) introduce new syntax that older compilers won't parse. The others (concise magic file names, forward-scan matching, implicitly opened existentials) are changes that affect semantics but don't change what code can be parsed. To me, that implies that the feature-check syntax (however it is spelled) shouldn't imply that an untaken if will not be parsed.
As for the $ vs. hasFeature, I'm bothered by the interim state of
#if compiler(>=5.7)
#if hasFeature(SomeFeature)
// new-fangled code
#else
// old code
#endif
#else
// exact copy of old code
#endif
I know it's an intermediate state, and 5 years down the road it won't matter, but we're designing this feature for folks who maintain compatibility with older tools, and it feels like we've missed the mark by adding a feature that they can't use cleanly. The amount of duplication required to use #if was brought up in other reviews (e.g., the primary associated types review), so the fact that "old code" in the example above has to be repeated twice bothers me.
Doug