Let us take `string-join` from SRFI 152, for example. It has a GRAMMAR argument, which can be a symbol out of a set of four. If SRFI 152 (or some successor) is designed with SRFI 209 in mind, it makes a lot of sense to turn this symbol argument into an enum argument (which can be dynamically type-checked). But there are two options: Either the argument becomes a single enum (symbol) or it becomes an enum set (of a single element). The latter would be the preferred form with the recommendation and would allow implementations as fast as if the options were given by raw numbers.
I agree that an enum-type would make sense in this case. However, I don't see the logic in using an enum-set: eqv? is no slower than fx=?.
Moreover, it would allow the compiler to inline code. (The latter would probably be harder if dynamically constructed enum objects would be passed.)
A compiler can do this in cases where define-enum(eration) is in use.
Do you actually want to forbid early error detection or make this optional?
The latter, certainly.
If early error detection is allowed, one should expect that good implementations detect the error early (even if just for the sake of a superior debugging experience).
By the same token, one should expect that (car 0) generates a compiler error (except on R6RS systems, where it is forbidden to do so), but typically nothing of the sort happens: the program compiles and then at best raises a run-time exception.
So a coding style by the programmer that enables early error detection (when implemented by the implementation) is very much preferable (and could be hinted at in this SRFI).
I think this is a matter for the implementation to mention: "It is more efficient in this implementation to use define-enum-type instead of make-enum-type where possible."
If all hings on whether we have procedural macros, I can only repeat my opinion that we should set up the basics first.
The type of procedural macros to be standardized has been and continues to be very controversial. There are people who detest syntax-case, and others who believe that explicit renaming is an abomination. This is not a matter that can be adjudicated by reason alone. R6RS decided on syntax-case in secret and said "Take it or leave it" to the implementer community. A great many of them left it. The whole reason *not* to establish this point early is to avoid such an outcome until a great deal of work is already behind us, building trust.
I am committed to a solution publicly arrived at, hopefully by consensus but more probably by majority vote. A straw vote taken very early in the process selected explicit renaming, but several people did not understand the importance of the question and indicated that they would have voted for syntax-case if they had.
Your Unsyntax system makes it clear that implementing both is perfectly practical, but that doesn't mean it will happen. In hopes of a resolution, this time I am going to ask the committee to vote on syntax-case and explicit renaming individually.
(By the way, I thought that Unsyntax had implicit phasing, but your "Meta definitions" post implies that it doesn't.)