Your thoughts are exactly what I've been stating from the very beginning, and I've repeated them several times. It's possible we're talking about the same thing but using different words.The issue with needing unique events is that it needs a unified approach. Because different hypothetical libraries assumed they were the only ones running they did not provide a way for other code to know what events were used. They could of provided a parameter to there own routines that designates a initial value for custom events and an additional way to know what events they reserved for their own use. In other words they need a cooperative and unified approach.
I agree that a unified approach is needed. The problem is that a library from an unknown author has no way to know which event numbers are already taken, because there is no single variable to track the next available number.
If we, as developers, all agreed by convention and documented that a global variable in the global scope (for example, EVENT_NEXT_CUSTOM_VALUE) should be used in our libraries as a marker for the next available event, that would be one thing. However, this rule would rely on every library developer adhering to it voluntarily, and there's no guarantee they would. Rules that aren't enforced at the compiler level are always broken. A gentleman's agreement relying on a shared variable implies responsibility from everyone towards everyone else. But how much responsibility do we truly have? Look at how many libraries have been abandoned and how many links are now broken. It's a good thing that at least someone is preserving this knowledge!
Therefore, I am absolutely convinced that a system for assigning unique numbers for custom events must be implemented at the compiler level, and not in any other way. Fred, these are thoughts for you, as the creator of the compiler
