How should KTextEditor allow to prevent calling Document::closeUrl?

KTextEditor::DocumentPrivate::onModOnHdClose() is the only place where KTextEditor calls closeUrl(). KDevelop never calls closeUrl() but simply destroys the KTextEditor::Document object when done. The commit message kdevelop/kdevelop@f47916f4 explains why calling closeUrl() is problematic for KDevelop (note that GitLab sometimes truncates long commit messages using ...).

I can see two ways of allowing KDevelop to prevent this closeUrl() call:

1. As proposed in the commit message kdevelop/kdevelop@f47916f4: instead of unconditionally calling closeUrl() and only then informing KDevelop about it by invoking KTextEditor::EditorPrivate::self()->application()->closeDocument(this);, onModOnHdClose() can emit a signal similar to ReadWritePart::sigQueryClose() before calling closeUrl(). KDevelop could then abort closing in onModOnHdClose() and invoke KDevelop::IDocument::close() instead.
2. onModOnHdClose() can invoke KTextEditor::EditorPrivate::self()->application()->closeDocument(this); and never call closeUrl(). KDevelop, Kate and RKWard already handle the closeDocument() invocation and thus should be ready for such a change. But Kile and KTechlab do not handle closeDocument(). Just tested Kile: closing a document in onModOnHdClose() replaces the closed document with a new Untitled document in master (an existing bug); if the closeUrl() call is removed from onModOnHdClose(), pressing the Close File button in the KTextEditor prompt has no visible effect, but if the user saves the "closed" document and then deletes its file externally again, the KTextEditor prompt does not appear again (two new bugs replace the existing bug).

The second approach has an advantage of simplicity (no new signal) but can cause regressions, especially in Kile and KTechlab. I'd like someone else's opinion on how to resolve this issue.