Actually, reading the issue the description is probably not accurate as to what's going on. Web worker execution never halted in previous versions, sorry about that... Here's a better description:

I'm talking about code where the main thread listens to web worker messages, and inside the callback for that, it calls some function to do work. 

And if you try to debug that function (or anything that is inside it), other invocations of that function keep happening in the background, and those don't break on the same breakpoint.

In previous versions, what (I think) happened was that those invocations, too, halted on that breakpoint (they got queued up until you fully continued execution of the code [so not just single line stepping]) and you could debug them one after the other. 

This, of course, had the drawback that when disabled the breakpoint and continued, it ran through all of those queued up executions, which could lead to quite a slowdown if you debugged a while without manually halting web workers. It's possible that this is why it was changed.

The main thread is single threaded, unless there are timers, promises, or other async things happening, the main thread will not process any message from the worker until the execution stack is finished.

We do not want to force the worker to halt as that would be even more confusing since a worker is designed to be able to always execute in another execution context (concurrently).

It is possible to write some hooks into your code to assist you in debugging like, set a breakpoint in the worker just before message is sent to main thread then step to after the postMessage occurs then keep worker paused while you debug main thread.

This is largely tricky because workers are allowed to queue messaged to main thread or to any channel including other works. This in theory means that works should be able to communicate with each other even if main thread is paused.

I am going to mark as WontFix, but if you feel strongly about this we can dive deeper into it.

Thanks!