Thanks for the example. I was able to get the consecutive block comments to happen and the problem is a bug in the handling of block comments in languages that do not allow nested block comments. That explains why you saw it in C and Java, but not Slick-C. There will be a hotfix out for this shortly.
I believe I know what was happening with the other problem of comment wrapping extending the right margin. It has to do with pasting. Actually, comment wrapping does not handle most paste events. This is simply because its impossible to know what to do on every possible paste. It could be one word or hundreds of lines. So we don't actually wrap or format on a paste and instead rely on the next keystroke triggering a wrap or format, which usually is acceptable.
You have stumbled on the case when this doesn't work. What the right margin should be for a comment is calculated on the first key stroke when you start editing that comment. If you keep typing there, we just use the cached value for the right margin. If you leave the comment, edit some place else, and then come back, the right margin is again calculated on the first keystroke. Letting long lines from pastes be wrapped on the next keystroke usually works because we just use the cached value for what the right margin should be.
What I think is happening to you is that you enter a comment and you do a paste before hitting any other key. This can leave a line past your desired right margin. Then you hit a key and the right margin in calculated. But because you have a right border, that long line is used as the right margin. This would not happen if you did not use a right border or if you were to type something else before the paste.
The good news is that the hotfix will address this problem as well. It will more intelligently handle simple paste events. Still no multiline or block pastes, but for most cases you will get wrapping on a paste event.
Thanks for reporting this,
-David-