Bug 207506

FYI. Might be useful for making OS-specific workdir
http://wiki.netbeans.org/NBIWorkingDirectory

Regarding usage of properties like "$M{...}" see
http://wiki.netbeans.org/NBIEngineStringResolvers

If version 7.1 of NB IDE was installed from OS account A, there is a .nbi directory in accounts A home path.
If later version 7.2 of NB IDE then was installed e.g. from OS account B, there is another .nbi directory in accounts B home path.
Regardless of the account from where the IDE initially was installed, it's accessible from all accounts, so why having it's installation details account-dependent?

I think, all this is a mess and can be confusing.

The confusing situation might not appear often, as Windows XP users tend to use one single administrative account for all there normal work.
But after a quasi-infection by some malware, 2 years ago, I limited the privileges for my user account, so had to use the administrator account for installing software. Since that time, I have .nbi in 2 locations.
I also redirected most user profile directories to my separate DATA partition to simplify user data backup and have a slim image for occasional system backup, clean from user data.
That's primarily why in the past I successfully insisted to move the NetBeans user data to %APPDATA% path.
Ideally IMHO, the .nbi-data should be in "Programs" path, as it belongs to the system installation, but not to user application data. A compromise could be the "All Users" path of "Documents and Settings". My dream is to have one "Programs\NetBeans" path with sub-paths for each version e.g. "7.2", and /maybe/ one for "Installer", but better inside each version path.
Another problem is the 2-pass install procedure of JUnit and other plugins, as after installing NB plattform from administrative account, but first starting NetBeans from user account, all plugins are installed in userdir. Beeing pedantic, this could be seen as a security hole, as it is possible to install a malicious plugin from user account. While installing NB plattform, there should be a flag to explicitly allow plugin installation from user account, and in case of limited user privileges, the plugin install mechanics could prompt for user OK, so no malware could silently install plugins.

My 2 + x cents,

I think you should remove dependency on https://netbeans.org/bugzilla/show_bug.cgi?id=49813 (which is rather obsolete anyway as many projects use this dot notation - read .git) - on the other hand you should consider working in this. In windows it is really awkward (read dirty) to see settings dirs in the user profile - moreover this one contains tmp and cache dirs which make backing up complicated. You should continue the laudable practice of https://netbeans.org/bugzilla/show_bug.cgi?id=196075 and split this to %appdata% and %localappdata%

Please consider

In v8.0.1, the .nbi folder is created in the installing user's folder. That is bad for shared computers, such as those in school computer labs. The user who installed NetBeans is most likely not the same user who will uninstall or upgrade it since users regularly come and go. So basically, the .nbi folder needs to be created in a spot based out of a place like %allusersfolder% or any other place that is not user specific so that the software can be reliably uninstalled.

Right now .nbi gets created in the home directory of the user who did the install.  This needs to be thought through.  

Consider a linux system that has many users. 

Each user could install their own version of netbeans (and that probably often happens). In this case, .nbi gets created in each user's home directory, and records the specifics of what that user installed.  So then when the user upgrades or uninstalls, the correct .nbi gets used.  That seems ok.  

Another common scenario on linix is for a system administrator to install a package such as netbeans as "root".  This would result in .nbi in the /root directory. I'm not sure, but that doesn't seem to be to be the right place for saving this kind of information. The "right place" probably varies with different linux distributions.  Probably the best way to make sure it gets done right in this scenario is to provide an installation package appropriate to the distribution.  For example, using yum, or apt, or rpm, etc..  Probably some of these exist, but I can see it would be a headache to make sure they are all kept up to date.

But here is the I am facing right now: Multiple different installations (e.g. different versions) done by the same user, but only one .nbi directory.  This just does not work. 

Why not put .nbi in /etc directory within the installation directory?  For example, if the netbeans.exe is installed in /bla/bla/netbeans-8.1/bin, put the nbi directory in /bla/bla/netbeans-8.1/nbi.  Wouldn't that make a lot more sense?  That way, I could have multiple different versions installed by one user, and they wouldn't conflict.  Also, I wouldn't have to leave stuff like this sitting in /root.