Some thoughts: The idea seems to be basically what Java does with `*.jar` files. And you say Tcl also does it. So why can they do this? They can because running both a Java application and a Tcl script requires a runtime environment (Tcl interpreter / JRE) on the target machine. So if the user must install this runtime environment anyway, it is minimal pain to add such a VFS to it.
Nim, on the other hand, does not depend on a special runtime environment (no more than C applications, anyway). So providing Nim artifacts in the form of a VFS would suddenly require users of Nim applications to install an additional tool. This is clearly an inconvenience and the question is whether the benefits of this VFS amortize this inconvenience. In contrast to Java, Nim libraries are usually compiled into the application. I have never seen a Nim lib that is dynamically linked to other Nim code. So for libraries, the source code is distributed. This will, of course, not always be the case – when a Nim library requires non-code resource files on its own, it will need a way to tell an application that it needs those files. This is where a VFS approach may come in handy. Resources are usually necessary for GUI libraries, which is a special case, but also may be useful for things like i18n. So we may need a more sophisticated approach for including libraries than just `nimble install`. But this can all be done at compile time with a bundling script. I think the better thing to have would be a bundler that can build native bundles for common target platforms, like an `.app` bundle for macOS, a `.deb` / `.rpm` package for some Linux distributions and an installer for Windows. This bundler would also have a minimal API for platform-independent access to application resources (which will be put in `/usr/share` on Linux, but inside the app bundle / installation directory in macOS / Windows). So, basically, I am suggesting that an API that emulates some kind of VFS would be good but the backend should be the application resource management native to the target system instead of some zipped file.
