Thanks for the documentation hint.

1.) I can well imagine that someone forgets to perform the proposed version jump in order to release the document for CMIS users. Thereafter, no CMIS users can checkout the document (conflict, constraint exception). 2.) If the web ui user drag'n drops a file (which triggers a document creation), than a versioning widget on the create form is not sufficient to avoid additional versioning of the document.

So, for me it is not really clear, why the imported document is initially a working copy.

There is a reason why the CMIS versioning state of NONE exists. For example, in some scenarios an optimistic locking scheme is more appropriate to manage concurrent access to documents than the pessimistic check-in/check-out version-centric model. CMIS supports optimistic locking using a changeToken. In many of these scenarios, there is no need to archive the document at every change so the overhead required to store every document version is avoided.

If you want to ensure documents created via drag'n drop in Nuxeo are versioned, I suspect you could plugin a custom VersioningService implementation to achieve that behavior. From my perspective, the default Nuxeo versioning behavior seems reasonable despite the fact it differs from the default CMIS behavior.

The default Nuxeo versioning scheme is "web-oriented", where people create documents with metadata through a web interface and when they're satisfied with it, record a snapshot through versioning. The initial creation can take several steps, go through a workflow or validation, and that's why we don't record a version at this stage.

If you only think in terms of file uploads then yes it makes sense to version things as soon as the document is created. We'll probably implement this in the future, but the reason for this existing behavior is as I state above.