Well it is an interesting question.
A direct answer to this question would be “because it has never really been required” ☺
I’ll explain a bit more.
IdentifyMatchingClassesAs is rarely needed in the first place. If you look at our out of the box pbds, you should see that none of them actually make use of it. That’s because most of the time, instrumentation is applied to a set of classes either inheriting from a same parent or implementing a common interface. The number of situations where one has to instrument a bunch of “unrelated” classes is quite low.
I had to use it once, because the customer’s application “business logic” layer consisted of a bunch of classes, with a common base package, but all they had in common was that their name would end with “Business”. If you ask me (and I don’t pretend to be a developer by any mean), that’s quite uncommon (and quite dirty, you don’t want your apps to look like that ☺).
There is a pretty valid use case for IdentifyMatchingClassesAs, and that’s when you’re trying to refine the instrumentation for an application. You’re not a developer, you don’t have the source code, you just want to see the “long running” not instrumented methods in your application.
This use case can now mostly be satisfied with Smart Instrumentation, so the need for this directive is even lower than it ever was.
Now as for “Bootstrap” classes, we’re talking about the first classes the the JRE runs at startup. So really core java classes.
I don’t know about you, but the ability to instrument these classes en masse definitely doesn’t seem like a good idea, unless you’re really trying to kill the app ☺
So my question to you is: What are you trying to do? Why would you want to instrument a bunch of bootstrap classes at once?