You absolutely can just build things and put them on base images without building or pulling the base image at any point. This is a central feature of ko, a simple container build tool for most Go applications: https://ko.build
I love seeing folks learn that container images are just fancy tar files and JSON and are therefore buildable by normal tools.
Along my own journey of demystification I made a few toy container image registries over the years that generated and served container images from nothing but the URL itself:
https://ko.kontain.me builds a go application on demand and serves it atop a minimal base image
https://apko.kontain.me builds a base image containing packages listed in the URL, again on demand.
The latest addition, https://git.kontain.me serves an image with the specified git repo already checked out in the image.
None of these should be used for anything serious but they were fun to make and play with. :)
random.kontain.me has been uncharacteristically useful in debugging image caching scenarios.
The filesize of a 3d animated splat is seemingly very small, and the method enables ~arbitrary FPS. But it seems the setup required to record it is still huge and expensive, which limits its usefulness.
Even with that there are some interesting use cases, eg. I'd love to be able to watch concerts this way, and freely move around the stage and crowd from any angle.
I did not get that impression from these docs or from a brief look through the gh CLI codebase. Can you point to evidence that makes you believe this is used to collect metrics about requests to other services?
Do people think that GitHub isn't already collecting and aggregating all the requests sent to their servers, which is after all the entire point of the gh CLI?
If you don't want your requests tracked, you're going to have to opt out of a lot more than this one setting.