The big one is about eschewing the global modifier method in lieu of just searching globally by default and not having another option. What a great way to artificially increase overhead! Moron.

Having a separate RegExp flag for the purposes of Unicode word characters and word boundaries: most excellent!

Rolling it up together with changed behaviour for \d and \D (use typically corresponding to code using parseInt, or maybe parseFloat): bad!

As long as these flags are regexp-global, that would impact use negatively the same way that you can’t have parts of a RegExp be case sensitive and other parts case insensitive, requiring the use of multiple RegExp passes and much additional flow logic to counteract bad underlying design.

While I’m sure there exist some case for (non-)Unicode-digit character groups (a subset of which, I guess, would be /[1234567890??????????]/, or /[0-9\u0660-\u0669] for matching Roman and Arabic-Indic digits) for text processing, layouting or formatting purposes, for more common use cases parseInt(’1234567890′, 10) produces 1234567890 but parseInt(‘??????????’, 10) unforgivingly yields NaN.