There are many use cases for expression of other object types that are neither cmis:folder, cmis:document, cmis:policy nor cmis:relationship. Examples include document-like types that do not permit versioning or do not permit a content stream (P8 has these), ancillary objects like annotations, or even objects that represent complex types which are currently not permitted in the CMIS 1.0 property model.

I see two ways these could be expressed. The first is simply to have implementations show cmis:object as the top of the types collections instead of starting with cmis:object's proper children. The simplicity of this approach is cancelled out however by the fact this this would likely break most CMIS 1.0 clients. So I have a suggestion which expresses the same idea, not as elegantly but without the backward compatibility issues.

In the object model, declare a new base object 'cmis:custom' which would serve as the base type for the entire genus of all of these currently CMIS/orphaned objects. It would have identical attributes to cmis:object
(i.e. Id, localName, localNamespace, queryName, displayName, baseId, parentId, description, creatable, fileable, queryable, controllablePolicy, controllableACL, fulltextIndexed, includedInSupertypeQuery )
though different values for those attributes of course. For example it would be recommended that the cmis:custom object be creatable=false since it is a more of an abstract class type. The implementation could optionally make cmis:custom queryable=true.

Note: No xml schema changes needed.

Thus 1.0 clients when querying types on a 1.1 server would just see 5 types instead of (4) as they do with 1.0 servers. The normal inheritance model would follow from there as is done with the other types. If cmis:custom was not supported then it would not appear in the type (children and descendants) feeds just like the optional cmis:relationship and cmis:policy behave today.