Unix-like OSes allow mounting disk images to explore their contents. But there's many more file formats where exploring files-inside-files is useful. Compressed archives, for one. Some file managers support those, but (imho) application-level is not the optimal layer to put this functionality.
Could be implemented with a kind of driver-per-filetype.
The only thing standing in the way of this today is that MacOS doesn't expose a user space file system API. You can do this on Linux, Windows, and BSDs today.
(No, file provider extensions don't cut it, Apple devs who read this, please give us a FUSE equivalent, we know it exists).
The fundamental issue is that macOS doesn't provide an API for this natively.
I was wondering what issues you were talking about, and then I found this - https://github.com/macos-fuse-t/fuse-t/issues/45 - data corruption
> The fundamental issue is that macOS doesn't provide an API for this natively.
The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. I don’t understand why Apple won’t.
Well, I understand that would require them to document it, ship public headers, and support it for external developers - but why not?
It would make macOS more of a general-purpose OS, would increase the amount of functionality from which third parties would benefit, but Apple themselves would likely not. That would increase the number and variety of tech support requests, ever so slightly but still, and would introduce a few new attack surfaces.
Instead, Apple's strategy is to tighten the macOS more and more, and turn it into a specialist OS completely controlled by Apple, with a few companies like Adobe and Ableton licensing access to its internals.
Stuff like this is of little interest to ordinary users (at least not directly), but appeals to developers
By de-emphasising the developer is experience, they are undermining one of the factors that got them to where they are today