I think a few cables got crossed in the conversation of the ticket! Ultimately, the idea for these container settings is that they absorb a lot of the concerns for laying out blocks, in turn removing a lot of the structural complexity from themes, but they should not remove control. The whole point, in a sense, is to provide more control but in a way that scales better and integrates better — block spacing is something that can act on all blocks, for example, even if you don't know what blocks are present.

In the current state it's not refined enough to allow variations in vertical rhythm (headings are generally a good example) so it should remain opt-in. We might need to introduce a way for declaring different levels of baseline rhythm that blocks can declare and themes can control globally. Once this setup is final the hope is that themes won't need to opt-in or out but merely configure a default and build upon it as needed. Of course, escape hatches will be necessary since absolute flexibility would be a requirement for multiple sites and setups. Once all is said and done we'll need to show various examples of how a "normal" theme might be setup compared to a fully locked down one.

A question of defaults is still relevant, though it might be more for themes showcased in the theme directory, in the sense that drastically different functionalities for users can be confusing when they switch themes and lose access to them, but I digress a bit there.

For the next few weeks we'll be establishing the major parts of design tools and global styles. Soon after a proper review needs to be conducted, including tweaking the defaults across all blocks (for example, what typography tools make the most sense to be present by default in a paragraph vs a heading). The iterative nature will mean a few things might need to start opt-in and move towards opt-out once things settle a bit more.