Starting compositor while it's being turned down will lead to a catastrophe. Thus, it can be simplified to m_state != State::Off.

Hmm, this method is hard to read. I suggest to use a switch statement.

s/Thus, it/Thus, the condition/

I'm actually not sure on that one. All the starting and stopping is done in sequence. So it might be possible to begin starting again while the stopping has not fully been finished.

This could happen in theory when compositing is quickly toggled on and off by a client.

while the stopping has not fully been finished.

finish() method doesn't have any asynchronous parts, so consider it as an "atomic operation."

True. But then the m_finishing variable was pretty useless. Because of that I assumed there was some funky callback stuff going on in the calls being done to the clients in between.

Can you give a code example how you think it should look?

No, we still need m_finished to delay deletion of support properties, don't we?

Something like this

switch (m_state) {
case State::On:
    // Comment.
    break;
case State::Off:
    if (m_selectionOwner) {
        qCDebug(KWIN_CORE) << "Releasing compositor selection";
        m_selectionOwner->setOwning(false);
        m_selectionOwner->release();
    }
    break;
case State::Starting:
case State::Sopping:
    // Comment.
    m_releaseSelectionTimer.start();
    break;
}

True. Having a member variable just for that looks like bad design to me in the first place but alright. What I would like to get rid of also is this isTerminating check in the beginning.

I have one remaining question. Why did you drop this if statement?

Relevant commit: 50ef02fa1b30c2c22d3cabc4f620e1654f9a5eae.

Good question. startupWithWorkspace is either called directly from start() (always in X case) or by signal (in Wayland case on startup). That should in both cases happen only once. I.e. we can split the signal out to future Wayland Compositor child class and disconnect the signal after it was received once.

I'm more interested in whether m_state can be State::Off by this time.

I would say in all relevant cases no. On X we always call from start() directly. On Wayland it should be only called through the signal once in the beginning and if at the same time it gets stopped we have likely some fatal problem anyway. We could investigate this more in the future but I feel it's not worth the time