In reply to Bjarne.

I thought (and other devs seemed to agree) that it would make more sense for the Heading block to generate its own id, rather than put that behavior in the Table of Contents block. (Having the Table of Contents modify sibling blocks feels un-block-like to me. I think block functionality should generally be self-contained or at least only affecting children blocks.) There's an open issue discussing how to implement that: https://github.com/WordPress/gutenberg/issues/6182.

It's also worth noting that modifying other blocks can be tricky to deal with, since it creates a ton of separate undo actions, which means that trying to undo the action becomes really janky. I just checked, and the Getwid Table of Contents block suffers from this issue. (Earlier versions of the core Table of Contents block suffered from similar issues, which is one of the reasons why it ended up being implemented the way it has been.)

I notice that the Getwid block allows you to choose which heading levels to display. I don't think it makes sense to have a separate toggle for each heading level, but I do think a "max heading depth" control would make sense, and I'd like to add it at some point if no one else creates a pull request for it first.

Concerning other things like changing the list style type (numbers versus bullets) or changing text color, I think a lot of styling stuff like that belongs in the upcoming Global Styles interface, and not as something that can be changed for every individual instance of the block. So I'm a lot more hesitant to add anything like that to the core block knowing how much themes themselves will be changing over the next couple of years.

It's also worth noting that the Table of Contents can be converted to a static List block (there's a button to do so in the toolbar). This allows for a whole lot more customization such as changing the wording of each link, and whatever else you can do with a List block.

Everything that gets added to core has to be supported for a long time, and I've already seen too many cases where something was implemented in a less-than-ideal way, and then changing it later on became twice as hard due to the need for some level of backward compatibility.

And note that in some cases, it makes more sense for plugins to extend core blocks rather than add entirely new ones. In fact, something like adding ids to all Heading blocks on the page could be implemented in a plugin without even having to modify the core Table of Contents block.