Saxon

I don't think it was an oversight; but it might not have been a good idea.

The new interface using Feature objects is certainly preferable for a number of reasons (a) it's strongly typed, (b) it's more performant (we found that searching for properties using URI strings was a noticeable cost). However, there are cases where the feature name needs to be constructed dynamically, including:

(a) the keys for setting XML parser properties which construct a composite URI (b) cases where the Saxon configuration properties are exposed via some other configuration API, for example as properties on the Ant XSLT task (c) internal uses, e.g. when processing a Saxon configuration file.

I guess it was (c) that led to the internal interface not being deprecated.

One of the problems is that deprecation has multiple purposes: in this case it was primarily intended, I think, as a gently nudge that a better interface was now available. But some people interpret that nudge as something more substantial.

Given that it's convenient to pass around URIs as references to features, I still think it would be nice if there was a published API that accepted a URI and returned the corresponding Feature.

Calling processor.getUnderlyingConfiguration.setConfigurationProperty(uri, value) just to avoid the deprecation warning seems...clumsy. It would be nicer to call processor.setConfigurationProperty(Feature.of(uri), value) or something, I think.

But we can also just close this. There's an explanation for why they API is deprecated in one place but not the other, so it wasn't just an oversight.