Summary of your points with my responses :


> 1) it doesn't exist in any other implementation that I know;

That's exactly why I proposed to discuss it with the developers of other 
implementations (I cited PCRE, Perl and PHP developers, there are 
others).


> 2) if implemented as default behavior:
>   * it won't be backward-compatible;

Wrong. This does not even change the syntax of regualr expressions 
themselves.

>   * it will increase the complexity;

Wrong. All the mechanic is already implemented: when the parser will 
store string index positions for a matched group it will just have to 
append a pair in the list stored in MatchObject.group(index) (it will 
create the list if it is not ealready there, but it should be already 
initialized to an empty list by the compiler) when the flag.R is set, 
instead of overwriting the existing pair without wondering if there was 
already another occurence of the same capturing group.


> 3) it will be a proprietary extension and it will reduce the
compatibility with other implementations;

Already suggested above. This will hovever NOT affect the compatibility 
of existing implementation that don't have the R flag.


> 4) I can't think to any real word situation where this would be really
useful.

There are really a lot ! Using multiple split operations and multiple 
parsing on partly parsed regular expressions will not be a solution in 
many situations (think about how you would perform matches and using 
them that in 'vi' or 'ed' with a single "s/regexp/replacement/flag" 
instruction, if there's no extension with a flag and a syntax for 
accesing the individual elements the replacement string).