But the implementation behind the other specification would have had to be inside an installed/started bundle, so they would have the BundleContext of their own to call createFilter under the covers.

Yes, but they would need to make arrangements to pass the BundleContext all the way down the call stack to the method which needed it (or stuff it in some well known static variable). This can be cumbersome to the code base. Especially since it could require methods in intermediate call stack frames to be OSGi-aware which may not always be possible if using 3rd party libraries.

@tjwatson this clearly depends on the implementation, just assume I have a bundle that contains code to work with filters but d not register any services/components, I then require to either create an activator and use some ugly static access, use FrameworkUtil (!) to get my bundle and hope it is started (or mark it lazy-start), just to use the bundlecontext to create a filterobject that actually don't care about bundle start/stop as it is completely stateless...

I don't believe we added FrameworkUtil.createFilter for any of these reasons. The only concrete reason I recall that we added this method was to make implementations of our various permission classes easier that require a Filter implementation under the covers. I can agree that, if it exists then someone will find a reason to use it.

to get my bundle and hope it is started (or mark it lazy-start)

On this point, that is a mistake in p2 that is proliferating into trying to make changes to the OSGi specification. Any bundle installed into the framework should always be marked for activation according to its activation policy (lazy or eager). If not, then I question why the bundle is even installed at all.

Any bundle installed into the framework should always be marked for activation according to its activation policy (lazy or eager). If not, then I question why the bundle is even installed at all.

I'm not sure I understand this, but if I install a bundle and then resolve it, I can use classes from it, but ti will not have a bundle-context to create filters, but other bundles (that are started) might still find it useful...

There have been so many issues and confusion over the decades around the lazy activation handling in p2 (and its predecessor Eclipse Update). Bundles marked for lazy activation are magically just treated as always available to be in the STARTING state waiting for a class to load to activate all the while these lazy activated bundles have a valid BundleContext. But bundles that do not use the lazy activation policy (which is most all others outside of the bundles that want to participate in the Eclipse platform) are not marked for activation unless some extra steps are taking to have a configuration unit associated with the bundle to have p2 actually start it.

This is not the norm for any other OSGi framewrok usage, in my experience. Normally bundles that are installed are also marked for activation. Not marking the bundle for activation would be the corner case. Unfortunately p2 makes that the norm and makes it difficult for "normal" bundles to be eagerly activated like they would expect in most all other OSGI framework usage.