Incorrect backref numbers when subpattern matches are referenced outside the regex
Various constructs (e.g. (?>...) or \g<0>) lead to js_regex adding additional capturing groups to the generated pattern. I understand this is necessary to emulate certain features in JS, but it leads to backreference numbers being incorrect when they're used from outside of the regex (e.g. in a replacement function, or when referencing subpattern matches on a match array).
There are solutions for this if you're open to emitting JavaScript code (e.g., a call to a RegExp subclass that users can optionally include). This is something that oniguruma-to-es does automatically (with an option to disable it), and is critical for some use cases. Perhaps js_regex could even support (and suggest directly importing) the EmulatedRegExp class from oniguruma-to-es (it's tree-shakeable, so users wouldn't need to bundle the whole library).
Feel free to close this as wontfix if this is not something you're looking to support.
AFAIK the only major use case of this library at the moment is running server-side validations (ActiveModel format checks) on the client side, and these only need a boolean result.
There used to be some usage or interest by asciidoctor and opal for which match contents might play a role, but i think js_regex is not used there at the moment @mojavelinux ?