Ok, I agree with John that we leave it to future discussion; this issue is much broader than just this srfi.
My immediate motivation is that I like to implement mapping as the same object as Gauche's built-in tree-map to avoid overhead of extra layer in every API. Marc's suggestion of requring disjoint from objects existing in the process wouldn't allow it anyway.
This is subtle indeed; e.g. for srfi-111 Boxes, I see the case that one wants a box to be disjoint from existing containers, for the box effectively works as a higher-order type: Using Haskell-ish notation, for any given type a, we want to distinguish 'a' and 'Box a', hence it excludes possibility of using existing container type as Box.
Mapping, on the other hand, looks more like an abstract interface (except that it has constructors). So it looks natural that Tree implements Mapping. We do want Mapping disjoint from List, but that's because we want to distinguish 'Mapping' and '[Mapping]' in the same reason as of Box; it's because of lists rather than of mappings.
However, probably talking about interface is too early; we already have an issue that, even this srfi suggests hash-based mappings being provided with the same API, this srfi alone doesn't allow one to write a generic algorithm using mapping interface that works for both comparison-based and hash-based mappings without writing manual dispatch for every call of mapping API.
I reckon that this issue would be addressed with some comprehensive srfi that deal with polymorphism. With that, we'll be able to apply generic mapping procedures on srfi-146 mapping objects or native tree-map objects. So I now support to leave the disjointness clause as it is now.