I think that is only to create the builder separatedly, to do that on the fly the spec uses the project.toml file:
https://github.com/buildpacks/spec/blob/main/extensions/project-descriptor.md#iobuildpacks-optional
https://buildpacks.io/docs/app-developer-guide/using-project-descriptor/

That is done here: https://github.com/buildpacks/pack/blob/main/pkg/client/build.go#L456C29-L456C51
For which it has downloaded the custom buildpacks if needed here: https://github.com/buildpacks/pack/blob/main/pkg/client/build.go#L368

Essentially it downloads the builder, and injects the new buildpacks on the fly.

There's a pull request to add a prepare step to the lifecycle, that would do that (https://github.com/buildpacks/rfcs/pull/238) but I did not have the time to see it through.

I think heroku has their own implementation that is managed by the heroku buildpack:set and such commands (and the UI), and predates those specs.

I would ask though if the question is if we want to allow users pulling any third-party buildpack or not (as discussed in T330102: Decision request - What buildpacks to allow and include for toolforge build service beta).

If that's part of the task, we should have a think at that policy.
If not, then we have to keep in mind that we want to have an allowlist or similar for the allowed buildpacks.
In any case, we can improve the way we do that today :)

This also enables multi-buildpack builds without the hack of injecting additional buildpacks after the detect phase.

I'm not sure what do you have in mind, but it seems to me that we still will need to do some hackish stuff to parse the porject.toml, and inject the buildpacks to the builder somehow in-between the lifecycle steps (similar to what we do now). Can you elaborate?