I briefly looked at your specifications. They seem to provide some very useful features laking in other formats, but I think you have still a long way to go to polish the specifications. The main issue I have with them is the lack of formal definitions for individual entities. I would recommend treating data normalization very precisly and defining every syntactical element in Backus–Naur form.[1] The specification of Unicode characters should be made independent of a specific serialization (such as UTF-8).[2] Formal definitions are extremly helpful to clearify edge cases and to implement a processor one piece after the other.
For example, instead of specifying uppercase/lowercase sensitivity in an extra section on "Letter Case", I would recommend defining the allowed character range for every item individually. In addition, it should be specified in detail how characters need to be handled by a conforming processor. Just for example: What Unicode version must be supported? The whole code range or only a part of this version? Is a processor required to check for violations of certain rules, such as illegal case? Should or can a processor normalize case or must it not? If it should or can, must it implement the "default algorithms for case conversion, case detection, and case-less matching" from the Uncode spec,[3] or may it, for example, deviate and support only a subset of Unicode characters?
To take up your own example, here is an edge case that is only very difficult to specify verbally, but can be made very clear in Backus–Naur form: Do you want to allow leading zeros for numbers? If so, infinitly many? A leading '+'? ...
It might be helpful to dinstinquish two phases for a conforming processor, namely checking syntactic conformity of an entity to its Backus–Naur form (eg. Is this entity a number?) and validating a syntactically correct entity in its context accoring to some validation rules (eg. is the number out of range?).
[2] For example, you are defining: "A string-like array MUST contain only valid UTF-8 characters.", but when I look at "Escape Sequences", you are using Unicode code points, and not UTF-8 byte sequences. -- Your sepcifications may, of course, require that data exchange must happen in UTF-8 (and should say something about byte order marks). Besides, they should not be conserned with any particular serialisation, but should only work with deserialised Unicode code points.
One thing I'm not sure about is how to define a BNF rule that says for example: "An identifier is a series of characters from unicode categories Cf, L, M, N, and these specific symbol characters". BNF feels very ASCII-centric...
For example, instead of specifying uppercase/lowercase sensitivity in an extra section on "Letter Case", I would recommend defining the allowed character range for every item individually. In addition, it should be specified in detail how characters need to be handled by a conforming processor. Just for example: What Unicode version must be supported? The whole code range or only a part of this version? Is a processor required to check for violations of certain rules, such as illegal case? Should or can a processor normalize case or must it not? If it should or can, must it implement the "default algorithms for case conversion, case detection, and case-less matching" from the Uncode spec,[3] or may it, for example, deviate and support only a subset of Unicode characters?
To take up your own example, here is an edge case that is only very difficult to specify verbally, but can be made very clear in Backus–Naur form: Do you want to allow leading zeros for numbers? If so, infinitly many? A leading '+'? ...
It might be helpful to dinstinquish two phases for a conforming processor, namely checking syntactic conformity of an entity to its Backus–Naur form (eg. Is this entity a number?) and validating a syntactically correct entity in its context accoring to some validation rules (eg. is the number out of range?).
[1] See https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form
[2] For example, you are defining: "A string-like array MUST contain only valid UTF-8 characters.", but when I look at "Escape Sequences", you are using Unicode code points, and not UTF-8 byte sequences. -- Your sepcifications may, of course, require that data exchange must happen in UTF-8 (and should say something about byte order marks). Besides, they should not be conserned with any particular serialisation, but should only work with deserialised Unicode code points.
[3] See sect. 3.13 of https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf