Displaying translation string counts and string errors is too much detail in the installer

This introduced a rather large UX regression in the installer, so raising priority to major and tagging hopefully as an RC target.

Those error messages persist through another ~8 minutes of the installer that comes after this page, too, as the translations get into place. The "2 translation strongs were skipped" warning in particular would be great to get rid of it we can; the green message is noisy but it's green so can be safely ignored.

Additional bug (I don't know if this bug requires a separate issue, or if this is the issue that will resolve this bug as well) -

During the Umami installation process, if the user is typing a certain password but types a different password in the "confirm password" field, an error is displayed:
The specified passwords do not match.
(which is good and expected)

The problem appears when the installation process continues, and that password error is still displayed (it is not relevant anymore, because to get to this stage the user must have typed the same password and confirmed password).

The problem continues when the installation is completed, and on the first page of Umami that the user is seeing - that same irrelevant error of mismatched passwords appears again.

(interdiff was not possible)
Rerolled patch #2, and added a check if the array exist in lines #394 and #404:
from:
if ($results['finish_feedback']) {
to this:
if (isset($results['finish_feedback']) && $results['finish_feedback']) {

After applying this patch here are the new screenshots -

During installation:

After installation completed:

I removed the extra isset I added in #7, since it only camouflage and hide a warning during installation but doesn't resolve the actual problem.

Warning messages during installation using drush si demo_umami:

call_user_func_array() expects parameter 1 to be a valid callback, no array or string given batch.inc:298                                        [warning]
array_merge(): Argument #1 is not an array batch.inc:298                                                                                         [warning]
call_user_func_array() expects parameter 2 to be array, null given batch.inc:298                                                                 [warning]
call_user_func_array() expects parameter 1 to be a valid callback, no array or string given batch.inc:298                                        [warning]
array_merge(): Argument #1 is not an array batch.inc:298                                                                                         [warning]
call_user_func_array() expects parameter 2 to be array, null given batch.inc:298                                                                 [warning]
session_id(): Cannot change session id when headers already sent AbstractProxy.php:94                                                            [warning]
Installation complete.  User name: admin  User password: tr9HsTpQqP                                                                              [ok]
No configuration objects have been updated.                                                                                                      [status]
Congratulations, you installed Drupal!                                                                                                           [status]

Additional insights from Slack channel after I asked for a hint about the 35 failed tests in #7:
@Gábor Hojtsy:
I vaguely remember when I worked on it I figured there are three kinds of batches from two files that are related and would need the same fix to be consistent. That is where it got real ugly because we need to add the same batch function at multiple places given the slightly different batch building in include files.

@alexpott
Yep what @Gábor Hojtsy is saying looks correct… something is going wrong in one of the places where the batch is being built.

Can someone confirm that this is an issue with 11.x? It has been 6 years since this was last confirmed.

This came around again as a daily BSI target

This seems more like a task vs a bug

Sure with things moving to OOP functions this will need a good amount of work.