Why?That only potentially works on that specific use case though, and even in that case it wouldn't update when new builds are made because the files generated by this add-on are inserted into the same directory as the XF default fontawesome icons, so if I symlinked all of that and XF updates FontAwesome the deployment process would overwrite that with the old versions in the copy of it from the NFS share.
The delopyment process just needs to take care of that symlink and follow it when writing files (instead of replacing it with the directory from XF ZIP).
I don't understand the problem here eitherEven if they were split into a separate directory that's not of as much use for environments running off of Docker images which have no sort of persistent filesystem and relies entirely on S3 for the data and internal_data filesystems and has an NFS share mounted for code_cache with a config.php edit pointing at it

If there is at least one writable persistent storage that can be accessed via OS filesystem (and even if that is only for
code-cache
), this could be used with some configuration changes (symlinks, etc.).As already pointed out, I'll add an option to use Flysystem - I just won't make it the default as I see more cons than pros to do that.