Saxon

Thanks for reporting it. I've reproduced it and understand the cause; fixing it is a bit more tricky.

Progress report:

What's happening is that the check on whether a map conforms to a given map type is using information held within the map about the types of the keys and the values, and returns true if and only if this stored type is a subtype of the required type. But the stored type information is not as precise as it needs to be, because it uses a "least common subtype" algorithm that approximates unions. So if the stored type isn't a subtype, then it's necessary to inspect each of the key-value pairs (which is not currently happening). Fixing this is complicated by the fact that iterating over the key-value pairs, in the case of a map whose keys are dates, requires access to the dynamic context (matching of dates depends on the implicit timezone), and no dynamic context is available at this point in the code.

It's not actually direcly connected with empty maps; compound maps are more to the nub. What's happening is that we have a map with two entries, and each the value-part of the entry is a map. Each of these two maps has an inferred type, but the logic for finding the lowest common supertype of these two maps is flawed. Rather than attempt to fix this logic, I have introduced code so that if the "crude" type of a map doesnt' match the expected type, we then iterate over the entries in the map testing each entry to check whether the key and the value both conform to the parameters of the required map type. The fix for this is complicated by the need to introduce a context-free way of iterating over the entries in a map; the existing mechanism (iterating over the keys, and for each key, getting the assoicated value) is context-dependent because the implicit timezone is needed for comparing date/time keys.

A solution has been applied on both the 9.5 and 9.6 branches; the 9.6 version is a bit smarter.

Bug fix applied in Saxon maintenance release 9.5.1.6