First a bit of background. In 9.6 and earlier, every implementation of a document node implemented the DocumentInfo interface, which itself extended NodeInfo. This allowed the DocumentInfo interface to provide capability defined for a tree as a whole, for example keys, document URIs, etc. The problem with the design was that in many cases we also want this functionality on trees that are rooted at element nodes. This came to a head with the decision in XSLT 3.0 that accumulators (unlike keys) could apply to non-document trees.
So we made a change: instead of DocumentInfo, we would put the "tree-level" information in a new TreeInfo object, which would be associated with every tree whether rooted at a document node or not. This means that in 9.7 DocumentInfo serves very little purpose, but we retained it to keep some commonly-used interfaces compatible. Most notably, it remains the return type of Configuration.buildDocument(). However, it is no longer true that every document node implements DocumentInfo, and in particular the root nodes of the tiny tree and linked tree do not. This means that the StandardCollectionURIResolver is quite wrong to attempt this cast: the code is clearly wrong.
This then interacts with another change in 9.7, which is a complete redesign of the API in the area of collection support. This was also motivated by specification changes, in particular the fact that collection() can now return any kind of object: for example collection applied to a directory containing JSON files can return a sequence of maps. Accordingly, the CollectionURIResolver interface of 9.6 and earlier releases was replaced by the CollectionFinder of 9.7. But we retained some support for CollectionURIResolver for backwards compatibility reasons. The StandardCollectionURIResolver (despite its name) is no longer used unless the application explicitly registers it, or a class derived from it, using the old interfaces. This explains why the exception wasn't encountered in our testing.
.