If I am understanding the discussion correctly, it is the intent of the author that the pattern-matching system be built upon with more features in future SRFIs. If that is the case, it may prevent confusion to revise the "Incompatible features should not be used" section so that instead of explicitly recommending against additional features, it explains that they are beyond the scope of SRFI-200. As it stands, it is unclear if additions to the pattern matching are compatible with SRFI-200 or not, as they are described simultaneously as "allowed" and "non-SRFI-200-compliant".
Hi!
Perhaps I should be clearer on this indeed.
There seems to be a linguistic problem here. It's just like with Leonard Cohen: the old songs of Leonart Cohen are the ones that were recorded when Leonard Cohen was young, and the "new" songs were written when he was old. (I suppose it also applies beyond Leonard Cohen)
We can talk about SRFI-200 compliance in terms of implementations (for example, the Racket matcher is SRFI-200-compliant) but also in terms of patterns themselves (and thus, for example, patterns that contain ellipses are non-SRFI-200-compliant).
I imagine SRFI-200 to be a "consensus" pattern language - or a subset that could be used in the Scheme programs that want to be portable between pattern matchers available on different systems.
Personally I do not intend to add more advanced features to this pattern language. But I imagine that more advanced features could be added (as John Cowan suggested, it is an option to write an SRFI document for the matcher described here as WCS).
One of the motivations for this SRFI was the set of extensions proposed in SRFI-201. It occasionally uses the phrase "underlying pattern matcher", because it was meant to be pattern-matcher agnostic. SRFI-200 serves as a reference for pattern matching, but SRFI-201 would be useful on systems that already support some pattern matching, even if it's not compatible with SRFI-200.