What problem does this address?

When creating a pattern and toggling 'Allow instance overrides' for a block, the block receives some attribute data that looks like this:

"bindings":{"url":{"source":"core/pattern-overrides"},"title":{"source":"core/pattern-overrides"},"alt":{"source":"core/pattern-overrides"}}}

This is the block bindings declaration, that declares that image block url, title and alt can be overriden within patterns.

A problem arises when the block bindings feature supports more attributes in the future. Because this data is saved in a post type, it isn't easy to update after the fact.

What is your proposed solution?

Don't use the bindings property for pattern overrides, and instead rely on the presence of a name

As mentioned in #59268 (comment), an option is to consider any named block as bound, and not use the bindings attributes at all for pattern overrides.

This may require some modifications to the block bindings API

Wildcard binding

Because patterns generally mark entire blocks as supporting overrides, if there were a way to declare that all supported attributes should be overridden, that might solve the issue ... perhaps using a wildcard?

"bindings":{"*":{"source":"core/pattern-overrides"}}}

Something that may be important to consider is that users may want to be able to mix bindings in the future, so inside a pattern they could also declare a binding to post meta, potentially even on a block that already supports overrides. I think that could still work here:

"bindings":{"*":{"source":"core/pattern-overrides"}, "url":"core/post-meta"}}

Though use cases are possibly unclear.