1. action_bulk_test.info.yml needs to depend on node, the shipped views are node based.
2. CKEditorAdminTest.php sets plugins the wrong way. @Berdir was not sure about this fix and neither am I. Will need a @WimLeers review.

Fixes figured out on my own:

3. block_test needs a block_test.schema.yml to describe block.settings.test_block_instantiation with its own setting.
4. Color module litters theme settings with its own settings. Haha. We need to set the color submit function early enough AND unset the color added elements. Ideally this form would be refactored because the quick-fix is not very nice, but that is definitely not in scope here.
5. Color test theme is missing its theme settings schema. See also #2382671: Automatically define schema for themes.

1. CommentActionsTest: the schema for the comment action was wrong in not pluralizing keywords
2. ImageDimensionsTest: uses an image effect with no settings that has no schema; we could provide that schema or just provide an empty fallback like everywhere else, which is what I did; this will fail the same way if the effect has any settings but not supposed to
3. SearchTokenizerTest: set the minimum_word_size at the wrong place once (it set it right at least one other place)
4. StatisticsReportsTest: defines its own block type but had no schema for it. Found #2391403: Statistics block not properly migrated, schema incorrect on the way. Normal bug, not to be resolved now.

1. One more fix in SearchTokenizerTest: overlap_cjk was not set in the right settings place one also.
2. CKEditorAdminTest used a llama_contextual_and_button plugin with a custom setting but that did not have schema. Also it was testing the result as 1 instead of TRUE.
3. CKEditorLoadingTest put a button at the wrong structure in the config.

Attached is a patch that fixes the fail in CKEditorLoadingTest. Apparently calling WebTestBase::resetAll() after installing a module — as recommended! — causes the wrong container to be used. I fear this might be a fairly widespread problem?
Simply removing the ::resetAll() call makes the test pass!

I'm still digging into the EditorAdminTest, but it's already certain that it's a similar container/caching problem.

Re #11/3: the answer to how did that test pass is if you don't add the button at the right place, the plugin is not added either. Later the same editor setting is used to compute the expected value, so if you add the button it compares values after that fact, if you add it at the wrong place, it compares values without that. Not sure how to make that more solid without hardwiring a WHOLE LOT of stuff, but not the scope of this issue :)

The vocabulary crud test was failing because even though it uninstalled the taxonomy module which uninstalled the taxonomy_crud module that provided a 3rd party setting, it kept the old (now invalid) config entity in memory. Then it only installed the taxonomy module again (not the crud module), so the crud 3rd party setting was invalid. To avoid this, the simplest was to remove the 3rd party setting for this test. We do not need it in this one. It is tested in other tests in this class.

So apparently EditorAdminTest's only problem was that the form was generating settings that weren't reflected in the default settings NOR in the schema. By making all of that use a single setting, the problem is now solved.

(The removal of the "default settings provided/altered by modules" concept in the other issue helped make this simplification possible.)