I have to admit, I kind of hate this.
I hate it conceptually because it's the kind of boilerplate we've always tried to avoid. I worry that people (or templates!) will defensively put compilerSettings at the top of every file, whether it needs it or not.
I also hate this particular design because it's incredibly wordy and syntactically complex. In most languages I have experience with, common pragmas at least have the virtue of being short. For example, I haven't written much Perl in the last twenty years, but I still have the pragmas you write at the beginning of a file memorized:
use strict;
use warnings;
Compare to something that uses a bunch of camel-case names and requires you to mix square brackets (in a really weird usage for the language!), parentheses, dots, and commas in a fairly arbitrary order. This is actually a pretty difficult syntax to use correctly without code completion.
I hate that this complexity isn't even buying us the benefit of using existing syntactic structures. If the proposal were for a built-in magic macro, you could at least justify the wordy, punctuation-heavy syntax as leveraging existing designs. But instead, we have something that's just novel enough to need a new syntax without actually taking advantage of the design space that a custom syntax opens up.
And—though this is admittedly peevish—I hate that compilerSettings is an introducer keyword with a capital letter. Didn't we decide not to do that with associatedtype?
I'm also concerned about some of the settings you want to permit people to change. Is every upcoming feature going to work correctly when enabled on a per-file basis? Do we really want people to specify a long list of warning categories to disable in every source file?
I think we should take a very hard look at which compiler settings we actually need to be able to change per file and which ones we simply think would be nice to change if we have a feature that could accommodate it. If we find that, for instance, the only thing we really need is main actor mode, maybe we could invent a one-off syntax specifically for that purpose and call it a day.
import DefaultMainActor // unprincipled but lightweight
If we do conclude that a flexible feature is the right move, I think we should decide on a design direction—either a really nice bespoke syntax or a syntax that reuses existing language constructs—and then lean into that instead of building something that has the worst of both worlds.