Thanks for documenting this bug ... so we first suspected that got fixed in the meantime but that is not the case. Well with publishing version 3 we do prevent any corruption happening to the content stream. So that is the good news. The ui continues to work and so will all cli commands. So this behaviour is fixed.

Now i can exactly reproduce the behaviour:

1. Created a document (id=document-node) with main content collection (id=main-content)
2. Created a headline in the main content collection (id=headline-node)

events at this step

change records at this step

3. Deleted the document

additional events at this step

change records at this step

Publish site does not work

#1729974980: Publication failed, events cannot be reordered as filtered: "Node aggregate "main-content" does currently not exist."

Discard site does not work

#1729974982: Discard failed, events cannot be reordered as filtered: "Node aggregate "main-content" does currently not exist."

Publishing or discarding other selective changes does continue to work, as long as the site is not attempted to be published.
The PartialWorkspaceRebaseFailed exception will continuously be thrown.

Now the problem is similar to the one of creating a new document and another new document within and attempting to publish only that: #5364

The ui request the node document-node to be deleted the publishing goes through the events and drops all events affecting the document-node. Applying all events not targeting the document-node does work for the happy case if there are no other changes but because the filtering dindt specify to drop also all affected children like headline-node the node creation will be attempted to be applied as remaining change but fails because its parents are gone already. The reason for that the node creation of the main-content does not fail is because its tethered and by discarding the parent creation event the main content collection is too not recreated.

But this scenario really shows the problems with publishing: ANY unpublished changes within a hierarchy will prevent that part of the tree from being deleted.

Regarding the proposed solution:

It should be possible to remove the change record instead, if it has been flagged as created and a deletion comes in.

The other change records must not be removed but rather tied together, possibly by sharing the same removalAttachmentPoint so they are published or discarded in sync.

As for similar cases we definitely want to extend the Neos ui to offer a "Publish whole workspace" or "Discard whole workspace" instead to allow resolving such conflicts directly. (see neos/neos-ui#3893)

Solving this via publish/discard whole workspace is just an escape hatch without any possibly for fine grained behaviour. Instead the change projection, or the core publish api has to be able to deal with this.