Don't have a clue what you're talking about with Fedora, it does exactly what you want.
Buildpacks have the advantage that the developer doesn't need to care about anything below their own direct dependencies. The runtime and OS are kept up to date by the platform, so you're relieved of the broadest angles of attack.
It's not a panacea. Just as with Dockerfiles, you have other upstream dependencies (Ruby gems, NPM modules, JARs etc) that need to be tracked and updated. Some of that can be delegated to the buildpack (ie, setting version range specifiers like '^1.1.2' or '1.1.*'), but that introduces some uncertainty about what is actually running in production.
Deis I believe did what we originally did in Cloud Foundry, which is to use Heroku's buildpack code. We ran soft forks for several years, adding only enough to allow execution in disconnected environments.
The Buildpacks team have since adopted a hard fork policy and have been replacing Heroku code with a uniform codebase called libbuildpack[0]. The new ones pass the same test suite we run and should work for Deis.
As for "Buildah", what about Deis and build packs deployed to Kubernetes? RH has gotten better in recent years with Openshift syncing closer to Kubernetes releases, but are still a far cry from how CoreOS handles things with Tectonic.