this seems incredibly easy to add given what they're done - just send a note to the author. I can't imagine how it wouldn't take seconds to implement.
So go on, try it right away :] I think it might be possible to get it done with breaking original regexp into group tree and look what each part did on concrete match from global search using non-global match on local instances. You'd need own regex parser and watch out for deep nesting.
Nevertheless, I prefer explicit color-coding highlighting the boundaries instead tooltips displaying the offset numbers.
anyway since they have the logic to already know what to put in the tooltip, making that number determine a color seems like it would be simple, almost as simple as appending it to the tooltip. (if indeed that's all that's missing.)
email the author your suggestion :)
Debuggex actually has the /g flag always enabled (the example above happened to have just one match), and it works for JS [1]. Groups for JS are indeed quite tricky. However, they come for free if you implement state visualization, since you need your own regex engine to do that (and can use said engine for the position of groups).
I don't know if that behavior for not matching newline matching is desirable since "\s" is supposed to include [ \t\r\n\f]. (See [1]) In any case, there doesn't seem to be an option in debuggex to make it behave like regex101 for my specific example.
I'm not saying your site's interpretation of Windows CR+LF is "wrong" but the other 5 online[1] regex testers don't behave that way on Windows Chrome browser. I also tested the regex and target text on desktop JGSoft RegexBuddy[2]. None of those required "\s\s" instead of "\s".
Debuggex at the least, is very idiosyncratic since the majority of the other testers don't treat CR+LF that way.
[1]regex testers tried with "([A-Z])\w+\s\w(\d.\d)" on Windows:
https://regex101.com/r/eB5jY1/1
https://www.debuggex.com/r/mci3WLNmHGTEatf6