It's an abstraction on the filesystem layer of your perl script, so that you can plug in other behavior than actually reaching out to the OS to access real files.

You'd want it for all the same reasons that you might use sshfs, gitfs, mount.cifs, etc. I thought I described the advantage of having it in userspace instead of kernel space fairly well in my post...?

I see... Interesting. So, does this mean you have to overload builtin functions like open() and seek() to make this work?

To be a 100% solution, I'd have to go one step further and intercept the C library calls. A 90% solution would be to intercept the Perl 'open' and 'opendir' and 'glob' opcodes. (once you have a file handle, you can tie it to intercept all the rest) But really, I'd be ok starting with a 60% solution of letting people opt-in by using a VFS module instead of calling 'open'. This is the point I was making about "have a Path::Class / Path::Tiny themed module" and "If "VFS::Path" happened to have your favorite API for traversing trees"

First of all, what is a virtual file system?

My take on their post was that they wanted to better understand what this was about.

You're asking what I want from Widget XYZ? What is Widget XYZ anyway? Substitute Widget XYZ for whatever. Educating yourself what Widget XYZ is prior to conjecture demonstrably leads to far more productive discourse, and importantly less wasted time for others to address the literal fundamentals. There's a massive difference in asking for technical help/input vs wanting to be spoon fed the basic principals under discussion, especially when there's so much info in the OP to begin with. "I can explain it to you, but I can't understand it for you."