The resolution of ENT-3959 (Augments classes are triggering incorrectly when . (period) is used) disabled the use of class expressions in augments' classes definitions. The documentation indicates the input is interpreted as an anchored regular expression. The docs did previously mention that you could use hard classes, but did not indicate that you could use a class expression, a string matching a class name is valid as an expression or as a regex.
However, using class expressions is at least equally valuable because it provides much more (and different) flexibility than just regular expressions. As it was expressed in the mailing list by multiple users, use of class expressions should be enabled again.
The problem is conflicting syntax between regular and class expressions. For example the dot character has a totally different meaning in the two interpretations.
Ted Zlatanov suggested the following solution:
Option 1: make class expressions the default in augments, change the
docs and tests, and enable class expressions to speak regex with
which was generally accepted as the best way to address this. However, it's not backwards compatible.
Changing the code to support regular expressions using the new /regex/ syntax would be easy and it is not conflicting with the syntax of class expressions. However, the question is how wide the support of this syntax should be. Supporting it only in augments' classes looks like a very random change from the general/long-term perspective.