I'm 👎 for such a change.

Do you mind explaining why? Personally I would be satisfied with just removing the typehint against the Event class, but that's probably not going to happen. I've never seen anybody use the stopPropagation feature of this component.

Current implementation forces us to break DRY. Every time we want to dispatch something, we need to wrap the object we really care about to custom Event class (just so it fullfills EventDispatcher contract) , in event listener we then have to manually call the method to retrieve such object from the wrapper and manually check for correct type retrieved from Event class.

Currently we have to encapsulate them to some Event class which means we cannot easily typehint against them in our listeners.

See the example here: #18873.

Bear in mind that BC break was added by a bot only because I forgot to change the default yes/no value

I've never seen anybody use the stopPropagation feature of this component.

I use it frequently (see e.g. lexik/LexikJWTAuthenticationBundle:JWTDecodedEvent#L47), like anyone setting the response of a kernel.request event since GetResponseEvent::setResponse() does stopPropagation().

@gadelat

I would like to use this to make some of our Doctrine entities (or some other object) events
I've never seen anybody use the stopPropagation feature of this component.

It seems like Symfony's contract doesn't satisfy your needs.
If you couple to a framework, you pay a price: you have to deal with their flaws.
You can make your own contract that would perfectly fit your needs, e.g.

namespace Gadelat;

interface EventDispatcher
{
    public function dispatch(Event $event);
}

interface Event
{
}

and use Symfony EventDispatcher as an infrastructure.

I agree that stopPropagation is a problem sometimes, events shouldn't contain this method, because it turns them into hooks. I explained my point here: php-fig/fig-standards#766 (in short, stopPropagation is not bad per se, but it should be separated from events).

If someone stumbles here and find he needs same thing, I've created separate event dispatcher library which doesn't restrict you in this way and is more appropriate for use cases like these https://github.com/ostrolucky/app-event-dispatcher