Herokuish defers a lot of this work to the buildpacks.
- Language autodetection performs the bin/detect script for each buildpack in order. Last one wins, unless you have a .buildpacks file, in which case we use the multi-buildpack executor. Not sure how it can be more... scrutable, but happy to hear suggestions (my github email in my HN profile has an email for contact)
- Besides bundling Heroku's official buildpacks (as it's meant to provide a compatibility layer with Heroku), herokuish doesn't have any opinions on your source code structure. If the official Heroku buildpack doesn't do what you think it should, you can definitely fork it and change the behavior (or even pull request it so others can benefit).
I can't speak to any specific Cloud-Native Buildpack (CNB) builder such as paketo, but Dokku should have support for CNB fairly soon (it's one of my top-priorities re: new development), at which point users will be able to switch between CNB and Herokuish (rather than force folks to migrate immediately). It will become the default at some point.
For Gitlab, I believe they are or are planning on providing experimental support for CNB. You can probably already use it today if you use pack directly in your pipeline.
As far as how these systems all compare, I wrote a fairly lengthy blog post comparing the usage of herokuish vs the Cloud Foundry and Heroku builder systems that might be interesting to read: http://dokku.github.io/technology/comparing-buildpack-v3-to-...