Hm. I can't reproduce that one. Do you have a example snippet for that behavior?

That might be just me. I used to write BEGIN: {}; with a semicolon after it, as you can see here, so it was doing something possibly excessive rather than actually wrong.

... and in at least one case things have got much worse, the case where it immediately throws an error about unbalanced parentheses whenever one presses the m or s keys. That should not happen and I can not reproduce it.

I couldn't reproduce it very well under emacs -Q, since it happens sometimes and doesn't happen other times. Here is a screenshot of a case when it happened. But it is reproducibly throwing the error message if I type m/ or tr/ instead of just m. The scrolling happens as well, which is much more annoying than the error message. I remember talking about the annoying error message to Ilya in about 2007 or so on comp.lang.perl.misc.

I used to write BEGIN: {}; with a semicolon after it

In this case, the behavior of CPerl mode is understandable. One of the more difficult things when parsing Perl is to distinguish in which cases you need a semicolon after a closing brace and in which cases you don't. In your example, the semicolon is not required, so it is actually a statement of its own. I'd say CPerl mode is, to some extent, entitled to move this statement on a separate line, if only as a hint that you might revisit your code.

By the way: Your BEGIN: is actually a label. If you want a BEGIN block, get rid of the colon.

it happens sometimes and doesn't happen other times. Here is a screenshot...

I can explain that, too. The message is technically correct. Read closely: End of ‘m} ... }’. The closing brace in the next line is interpreted as the starting delimiter of the match. That's weird, but it is actually valid to write m}foo}. The two numbers in the message are the character positions of the closing brace and the following newline, so M-g c 462 will take you to the closing brace. This is, in fact, the same situation as when you type m/ without a closing delimiter.

Without that strange scrolling (which I still fail to reproduce), the message is harmless and will disappear as soon as the closing delimiter is entered. Since the message is also an indicator that syntax highlighting and indentation will not work correctly until the closing delimiter is found, I'd hesitate to just suppress it.

I'd say CPerl mode is, to some extent, entitled to move this statement on a separate line, if only as a hint that you might revisit your code.

I don't think it's useful but it's not worth arguing about.

Without that strange scrolling (which I still fail to reproduce)

With emacs -Q I got the scrolling every time the error message was produced. It is a huge nuisance to deal with this scrolling.

Since the message is also an indicator that syntax highlighting and indentation will not work correctly until the closing delimiter is found, I'd hesitate to just suppress it.

That is absolutely ridiculous. Pressing the "m" key or the "s" key should not cause an error message to appear, especially not because of the extremely faint possibility that the user actually wants to start their regex with

m
}

I don't know of any other language mode in Emacs, or even another instance in cperl-mode, where an unfinished statement of any kind, like a /* in c-mode or an open quote " without its closing quote causes an error message to appear. This unwanted error message is a truly exasperating nuisance.