Thank you for your feedback. Let me add some comments under your meaningful feedback.

you said: "I would suggest that’s probably a slight exaggeration. The constrained DSL for writing Dockerfiles is certainly not ‘very’ hard and if this is your typical process ..."

Let's suppose a scenario where you have 100 microservices, and each of them needs a Dockerfile. Initially, it seems manageable, but one day you may need to upgrade their JDK version, requiring updates to 100 files. Every new change needs to be applied to 100 projects! I think my article can be useful for teams who have many microservices and find change management time-consuming and obviously, it's exaggerated for teams with a small number of microservices. Another reason is that, typically in large companies, the DevOps team is responsible for dockerizing the development team's projects. Often, DevOps engineers may not have write access to the development project to commit their Dockerfile changes. In this case, buildpacks may be helpful because they do not require a Dockerfile at all. Usually, developers do not have knowledge about Dockerfiles, so managing Dockerfiles for them can be challenging.

you said: "ontinuing with security, you state this is ‘enhanced’ … how so ? ... ... Is it possible to pass these sorts of constraints to the non-Dockerfile / non-daemon build tools ?"

Yes, I agree with you. In terms of security, the buildpack solution can increase the attack surface and may not be as customizable.

you said: "How is image versioning achieved"

Image versioning can be done as usual, and you can pass your desired image name and tag to the buildpack. It's up to you whether you want to use the latest tag or your semantic versioning tag.