It does not make sense to conduct something like "performance review" in a large corporation for my proposals concentrating on "soft-semicolon" idea and ignoring all others. As if it is the only one worth any discussion.

Others have already contributed their thoughts on the rest of your proposals, which I generally agree with and (more significantly) you haven't disputed. IMO, the primary reason that all the discussion is focusing on soft semicolons is because it's the only point you're attempting to defend against our criticisms. There was also a brief subthread about your ideas on substring manipulation, and a slightly longer one about alternate braces which close multiple levels of blocks, but those only lasted as long as you continued the debate.

In a way, it is a debugging aid that allows to cut the number of debugging runs.

Seems like just the opposite to me. It may allow you to get your code to run sooner, but, when it does, any semicolon errors will still be there and need to be fixed in additional debugging runs. Maybe a marginal decrease in overall debugging time if there's a line where you never have to fix the semicolon error because that line ends up getting deleted before you finish, but it seems unlikely to provide any great savings if (as you assert) such errors are likely to be present on a significant proportion of lines.

Also, even if it does cut out some debugging runs, they're runs with a very fast turnaround and little-to-no cognitive effort involved. According to your "BlueJ" paper, even rank beginners need only 8 seconds to fix a missing semicolon error and initiate a new compile.