Agree with @mbien This also appears to be a VSCode / LSP only issue? This should not be fixed this way, and if the issue is not in the IDE, should not be fixed there but in the LSP integration.

This does not (now) have a workable solution IMHO; the close could be done, iff the process is running headless, or can be conditioned by 'branding API' which would default to "do not close" and NBLS distribution would brand it to close.

But the problem is NOT just maven-specific, it's general, for all opened editor types: if the SaveCookie.save() is invoked, it modifies the on-disk file, LSP client might (and vscode does) recognize it as external modification and will inform LSP servers with didChange -- which actually causes the Document in NB become modified with duplicate contents.

Most proper solution is to relay the actual write to file to the LSP client (quite hard), or "somehow" detect that the didChange actually originates from the save (also quite hard). But we should work on that somehow.

@sdedic sounds fun! Perhaps something like an on-save task to save the modified regions somewhere like a document property. Depends whether NB and LSP idea of range matches?!

Still, if it can't be solved generically (which would be ideal) I guess branded close would be OK. Headless was pointed out to be a problem in another PR recently IIRC.