Yeah, it's a tricky one; it's good to shell out to buildx because the alternative wasn't great, but it also means that the buildx bake command-line now becomes a formal contract / API for compose.

I wonder if we should consider moving the options-struct-to-command-line-flags conversion to a utility package in buildx; that way changes made in the buildx command-line will stay in lock-step with the code to set those flags (e.g. if a flag is added / removed / renamed / changed, the buildx maintainers can make sure the code that compose uses to call buildx bake is updated as well and set the right version-switch.

Perhaps it would even be an idea to have a (hidden) flag that acccepts a JSON-struct with all the options - that would have a more structured way to pass options to buildx when invoked; i.e., something like

docker buildx bake --___bake_options='{"version":"v0.29.1", "progress": "rawjson", "provenance": true .....}'

• Some version in that struct could tell buildx bake what version was expected to be used by compose, which could allow buildx bake to adjust things where needed (or detect "unknown fields" and produce an error that a newer verrsion is needed).
• Some of those options could even be implicit (e.g. when using __bake_options, then always use rawjson)

@crazy-max any thoughts? Would something like that make sense to do? (i.e. a flag or subcommand to execute buildx programmatically?)