Original text:
"[^]", which according to this grammar would parse as a positive character class containing the single character "^". <del> This is essentially XSD regexp without character class subtraction and multi-character escapes such as "s", "S", and "w". </del>  An I-Regexp implementation MUST be a complete implementation of this limited subset.  In particular, full Unicode support is REQUIRED; the regexp flavors.  Thus, they are omitted from I-Regexp. Not all regexp implementations support accesses to Unicode tables <del> that enable executing on constructs such as "p{IsCoptic}", although the "p"/"P" feature in general is now quite widely available.  While in principle it's possible to translate these into codepoint-range matches, this also requires access to those tables.  Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance. </del>  7.

Reviewer comments:
I think it is better to support script names than block names for and . Unicode block names are not supported by regexp implementations an interoperable way. Block names as specified in URL allow ASCII alpha-numerics, hyphens and spec. Unicode says these names are supposed to be matched using URL (which says to ignore case, whitespace, underscore, hyphens, and any initial prefix string "is"). But implementations don't do this and compare names using a wide variety of different rules (as partially described by "Unicode blocks" section of https://www.regular-URL). Usage of block names can easily be replaced by ranges. Furthermore, block names are not covered by the Unicode stability policy. Scripts names don't have such a wide range of characters (there are also 4-char short script names) and scripts are generally preferable to blocks for regexps as explained here: URL Script is in the minimal list of properties that Unicode requires but block is not URL
Thank you! Very useful input. We are having an interim meeting (per web conference) of the JSONPath WG at this very moment; I'll look at this later today.
I just looked again at XSD and see that sadly it doesn't support scripts in . Every major regex implementation that I am aware of that does Unicode and does support scripts (Go, PCRE, Java, C#, Ruby). So if XSD compatibility is crucial (not sure why it would be at this point), my suggestion would be just to get rid of blocks. One could argue that supporting only the general category in is consistent with not supporting character set intersection/difference: once you have multiple things (e.g. script and category), you really need to be able to have intersections/differences of them.

Revised text:
"[^]", which according to this grammar would parse as a positive character class containing the single character "^".  <ins> This is essentially XSD regexp without character class subtraction, without multi-character escapes such as "s", "S", and "w", and without Unicode blocks. </ins> An I-Regexp implementation MUST be a complete implementation of this limited subset.  In particular, full Unicode support is REQUIRED; the regexp flavors.  Thus, they are omitted from I-Regexp. Not all regexp implementations support accesses to Unicode tables  <ins> that enable executing constructs such as "p{Nd}", although the "p"/"P" feature in general is now quite widely available.  While in principle it's possible to translate these into character-class matches, this also requires access to those tables.  Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance. </ins> 7.