This patch is similar to the original idea by @noisysocks b04425a only the filters are in render() and run before the inner WP_Block is instantiated (same as how they run for the top/parent WP_Block).

The filters have _inner in the name to distinguish them from the top block's filters. The same context could also be provided in a different way, perhaps. Ideas welcome :)

This patch is similar to the original idea by @noisysocks b04425a only the filters are in render() and run before the inner WP_Block is instantiated (same as how they run for the top/parent WP_Block).

Clever! That addresses the main criticism of my original approach which was that the filters were being called in WP_Block::__construct and not WP_Block::render. Admittedly it breaks encapsulation to have one object mutate another, but I don't see why it should matter in practice, and both objects are of the same type.

The filters have _inner in the name to distinguish them from the top block's filters. The same context could also be provided in a different way, perhaps. Ideas welcome :)

I do not like this. It creates extra work for plugin developers as they'll have to define two filters instead of one. Blocks should work the same way regardless of whether they’re nested inside another block or not.

Hmm, tests seem to fail globally at the moment, something about mismatched cert. 80695cf should be fine, tests pass locally.

it breaks encapsulation to have one object mutate another, but I don't see why it should matter in practice

Right, to get to the inner blocks you'll need to render the top/parent block. However there's a pre_render_block filter meant to short-circuit the rendering including any inner/nested blocks, so the results can be very different if that filter is not applied. Not sure we can do anything to avoid/delay running that filter...

I do not like this. It creates extra work for plugin developers as they'll have to define two filters instead of one. Blocks should work the same way regardless

Yeah, devs will have to use both "top" and "inner" filters. Having a different name makes it very clear the currently filtered block is inner. Blocks should work the same way but they don't, and most look very differently when nested. Also was thinking it may be useful to pass some more context to the inner filters, but may be redundant.

Updated the PR and changed the filter names to match. Context is provided by adding another param: $parent_block which is null for top level blocks. That should be enough for inner blocks imho.

Blocks should work the same way but they don't, and most look very differently when nested.

I think this point is valid, maybe "some" not "most", but it's a little inconvenience that I think adds more control IMO.

Yes but often the reason a block looks different when nested is only due to styling. The HTML will be the same. The most common use case for these filters is to slightly change the HTML. I think that plugin developers and theme developers will expect that the filters do this regardless of whether the block is nested or not.

Updated the PR and changed the filter names to match. Context is provided by adding another param: $parent_block which is null for top level blocks. That should be enough for inner blocks imho.

I agree. Perfect 🙂

Fixed in https://core.trac.wordpress.org/changeset/51894.