Refactoring hazard when using legacy static RegExp methods in conjunction with instances of proper subclass of RegExp

[claudepache]

As currently specified, there is a refactoring hazard when code such as:

var rx = /(foo)/;
rx.exec(str);
var p = RegExp.$1;

is refactored as:

class XRegExp extends RegExp { /* ... */ }
var rx = new XRegExp("(foo)");
rx.exec(str);
var p = RegExp.$1;

since RegExp.$1 could silently return an incorrect result.

For the sake of debuggability, we should ensure that, RegExp.$1 will throw an error when it is referred after doing a match with a regexp that don’t want to update RegExp.$1.

[claudepache]

Reopening this issue, because its resolution was reversed by 5e0f68fba964e689ec71897819232e93a3620f7d.

I'm not sure that there is much value into adding smartness on such a feature; so I'm waiting others' advice before resolving.

[claudepache]

Covered by #6.