Change:
Signed-off-by: Tim Bray Based on our email thread with James, and a couple of minor editorial touch-ups.
LGTM, thanks.

Discussion:
This specification describes an interoperable regular expression flavor, I-Regexp. <del> This document uses the abbreviation "regexp" for what are usually called regular expressions in programming.  "I-Regexp" is used as a noun meaning a character string which conforms to the requirements in this specification; the plural is "I-Regexps". I-Regexp does not provide advanced regexp features such as capture groups, lookahead, or backreferences.  It supports only a Boolean matching capability, i.e., testing whether a given regexp matches a given piece of text. </del> <ins> I-Regexp does not provide advanced regular expression features such as capture groups, lookahead, or backreferences.  It supports only a Boolean matching capability, i.e., testing whether a given regular expression matches a given piece of text. </ins> I-Regexp supports the entire repertoire of Unicode characters. <del> I-Regexp is a subset of XSD regexps XSD-2. </del> <ins> I-Regexp is a subset of XSD regular expressions XSD-2. </ins> <del> This document includes rules for converting I-Regexps for use with several well-known regexp libraries. </del> <ins> This document includes guidance for converting I-Regexps for use with several well-known regular expression idioms. </ins> 1.1. <ins> This document uses the abbreviation "regexp" for what are usually called regular expressions in programming.  "I-Regexp" is used as a noun meaning a character string which conforms to the requirements in this specification; the plural is "I-Regexps". </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in

matching regexp is needed in a data model specification or a query language expression. <del> A brief survey of published RFCs yielded the regexp patterns in Appendix A (with no attempt at completeness).  With certain exceptions as discussed there, these should be covered by I-Regexps, both syntactically and with their intended semantics. </del> <ins> The editors of this document conducted a survey of the regexp syntax used in published RFCs.  All examples found there should be covered by I-Regexps, both syntactically and with their intended semantics. The exception is the use of multi-character escapes, for which workaround guidance is provided in mapping. </ins> 3.

5. <del> (TBD; these mappings need to be further verified in implementation work.) </del> <ins> The material in this section is non-normative, provided as guidance to developers who want to use I-Regexps in the context of other regular expression dialects. </ins> 5.1. <ins> Common multi-character escapes (MCEs), and character classes built around them, which are not supported in I-Regexp, can usually be replaced as shown in tbl-sub. Note that the semantics of "d" in XSD regular expressions is that of "p{Nd}"; however, this would include all Unicode characters that are digits in various writing systems, which is almost certainly not what is required in IETF publications. The construct "p{IsBasicLatin}" is essentially a reference to legacy ASCII, it can be replaced by the character class "[u0000-u007f]". 5.2. </ins> Any I-Regexp also is an XSD Regexp XSD-2, so the mapping is an identity function.

this specification an implementation of XSD 1.0 regexps is equivalent to an implementation of XSD 1.1 regexps. <del> 5.2. </del> <ins> 5.3. </ins> Perform the following steps on an I-Regexp to obtain an ECMAScript regexp ECMA-262:

Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/". <del> 5.3. </del> <ins> 5.4. </ins> Perform the same steps as in toESreg to obtain a valid regexp in PCRE PCRE2, the Go programming language RE2, and the Ruby programming