Thank you for your detailed and direct response - albeit a somewhat discouraging one 
I’m not expecting Fly to ever model itself after or ever become Heroku, but given your own focus and existing guides on migrating from Heroku, and the removal of Heroku free product plans, making the transition from Heroku to Fly as seamless as possible would seem to align with Fly’s interests.
That being said, the friction-less way secrets/environment is handled on Heroku is certainly something to take inspiration from, with secrets being defined in one place alone and both building and running the application using these without any extra action.
As @kurt says in one of the linked threads:
We designed the secrets this way intentionally. Admittedly, we didn’t expect Heroku to drive away their users, or we’d have done some work to make this part smooth.
This not being - for the time - “smooth”, official docs or guidelines on how to re-create or just cope with having multiple secrets in a real-world scenario would at least make somewhat up for it. The build-time secrets documentation is sparse, and the example is at the border of being too simple to be useful.