You should also change the id accordingly to the class name, is that a possible BC break?

Not really, asrequest_listener can easily conflict with an existing service. But having a disconnect between the class name and the id is strange.

I suggest, whatever the id is, to add it to the changelog.

To me, this belongs to HttpKernel: it's a low level HttpFoundation exception (the only one), and HttpKernel job's is to map HttpFoundation to event's world, and deal with any kind of events, exceptions included. It's HttpKernel's responsibility to convert HttpFoundation exceptions to HttpKernel's world.
It's not optional at all, and existing HttpKernel users (e.g. Drupal) need to get a BadRequestHttpException that they already know how do deal with. Not this ConflictingHeadersException that comes from lower levels.

The listener below is a nice to have, that adds an early check in the request management process. Totally optional and a smooth feature for the FrameworkBundle.

Thus the split I made here.
That's only my humble opinion and maybe I miss the thing, so I'll move to the listener if you're sure it's the right place.

That's indeed much better now. 👍

these changes seems unrelated

yep, I'm debugging travis right now, this PR triggers situations that are not handled correctly today, please don't merge until it's green. I'll post a notice here.