Apt patterns allows matching on criteria besides strings such as searching for all packages with broken dependencies. It also allows combining different search criteria in various manners which would be difficult or impossible using just a regex search. If you want to just match packages using a regex against package names that is still possible using the name apt pattern.
I would suggest reading the apt-pattern man page referenced before passing judgement.
> difficult or impossible using just a regex search
I am sorry but this isn't true. I can prove it.
Regex is used to parse the program itself that runs APT, this is called Lexical analysis[1]. GNU Bison and Flex [2] are lexical analyzers for example that compile a lot of code we write today. So whatever pattern matching code was written in C as part of the APT 2.0 package, that code itself is read and compiled by regex. So, it provably cannot be impossible to do a match using this new feature you're referring to that cannot be matched using plain old regex. Difficulty is subjective depending on who the target demographic is.
All these things are actually moot - it doesn't cost you anything to keep Regex option to search for some package names, perhaps a bit of additional code to maintain. Also, other means of pattern matching can be added in addition to regex search feature. Why not both?
You're missing the point and being patronizing while doing it. Regex search can only match package names. APT's flags lets it match on other attributes as well, which a simple regex cannot interact with.
If you try to install libc++-dev and that package doesn't exist for whatever reason, you probably want an error message, not a regex match to libc-dev. Interpreting the argument as a regex violates the principle of least astonishment.
I always get confused how trying to install clang++ spews out a hundred messages about how it matches a huge number of packages. Fortunately they conflict, so it doesn't then try to actually install them.
Regular expressions are completely unsafe. See the clang++ example, which matches every package containing clang+ (that is 'clan' and one or more 'g'), unless of course somebody uploaded a clang++ or a clang+ package....
glob style wildcards are more common, though, in that context, anyway. It would be safe to re-enable those, but I'm not certain this provides a sensible user experience improvement.
Seems like a pretty big breaking change.