I've been following this, and I would take a slightly different approach.
1. Serve all apps under /{app}/releases/{version}/{path} as you have them organized in the deployment structure in the file system.
2. Forget about symbolic links and other makeshift versioning/defaulting in the file system.
3. Use a keyval mapping to handle redirections (307) of /{app}/current/{stuff} to /{app}/releases/{currentVersion}/{stuff}, where the keyval mapping provides {app} => {currentVersion}. You can update an manage this during deployment.
We usually include this in a CI/CD pipeline after deployment to dynamically switch to the last version (using a curl request to the NGINX API). If you can't use keyvals, use a static map and dynamically generate that "map" directive's mapping. Restart NGINX to reflect changes. Keyvals let you do this on the fly.
The major advantage of this approach is with updates. You are most likely going to run into issues with browser or proxy caching if you provide different versions of files/apps under the same path. By having a canonical form that respects the version structure, you are avoiding this altogether. Yet, you have the flexibility to run hotfixes (replace existing files in an existing version without creating a new one), or experimental versions (which won't update the "current" pointer).
I would try to keep the complexity low.
Cheers,
--j.
