Does really all need to be reverted? Or would it be enough for getDispatcher?

I think it is fine, better to be safe.
All events related things is delayed to 7 at least, anyway

Hi @Fedik, thanks a lot for your attention.

Now a question, probably for someone else, what exactly is the problem:

Having this:

public function getDispatcher()
{
    if (!$this->dispatcher) {
        return Factory::getContainer()->get(DispatcherInterface::class);
    }

    return $this->dispatcher;
}

instead of this:

public function getDispatcher()
{
    if (!$this->dispatcher) {
        @trigger_error(
            \sprintf('Dispatcher for %s should be set through MVC factory. It will throw an exception in 7.0', __CLASS__),
            E_USER_DEPRECATED
        );

        return Factory::getContainer()->get(DispatcherInterface::class);
    }

    return $this->dispatcher;
}

or in future, instead of nothing.

Yes, you understand it correctly, what is the exact reason for removing this piece of code either now or in the future?

It seems logical to me. The system does not have a dispatcher, so it creates one. We proceed in the same way with all the parameters in the settings. The system does not have a parameter value, so rather than throwing an error, it simply selects the default value. I would assume the same here. The system does not have a dispatcher, so we simply take the default.

I understand the ideological reasons, but I am more concerned with the practical ones. Let me explain with an example:

From an ideological point of view, we will remove File::exists or Folder::exists because we can simply do this using pure PHP (although not 100%, because we still use Path::clean inside these functions). I understand that. But from a practical point of view, this will eliminate backward compatibility for 95% of extensions, which will ultimately hurt Joomla users.

Is removing three lines really beneficial for the overall ecosystem?

Thank you.

I have tested this item ✅ successfully on 5323414

Before change:
Call to a member function getGroup() on null based on empty filterForm object

After change:
Everything is OK.

In all other places getDispatcher() will throw an exception when it was not set.
Model/View should not be different.

The dispatcher should be set while creating the class instance via constructor or setter method. For components which uses service providers and MVCFactory this will happen automatically.

We added this code to give to extensions time to adopt. If they creating Model/View instance outside of MVCFactory they should set dispatcher on their own.

We should at some point get away from using Factory::getContainer() in such way. At least that the idea.

I have tested this item ✅ successfully on 5323414

RTC

Thanks @Fedik and @PhocaCz, @OctavianC for the tests

Don't forget to revert the manual pr as well.