There is no issue with using a real physical drive called P: nor a genuine, physical partition similarly called P: , nor a simple subst command, nor (surprise, surprise) a vnc\\ 'drive'
There is nothing sacrosanct about P:\ by the way. It is not hardwired. It is simply a convenient 'label' to mean any drive:\ letter that gives you a thrill. Many folks use Z:\ for Dayz (either because it makes more sense, or so that they can keep the master config bin, stringtables, and shaders, quite separate from Arma3. (no P:\drive setup can share these across engines)
The subst was there in the 'bad old days' because physical drives to achieve the same thing were a) expensive and b) couldn't be physically cabled to a pc's mother board which swallowed 'D:' for cd roms etc. There is almost no advantage in using it these days when drives and sata connectors are so cheap. And, the whole idea of having a separate drive (read backup) is appealing when your main drive goes bang OR, you simply want to move Bis Everything to another PC sans pain and suffering. (often as a result of C:\ going awol, or simply due to a shiny new pc purchase.
The only real value of having a subst these days is to share the root of P:\ (eg C:\ArmaWork or god forbid, C:\ArmaTools). with programs that are hardwired to only download to C:\PinkElephant. Publishing your source projects to bis/steam might be one such example. I don't publish to bis anything so I don't know how flexible these things may or may not be. The other use is protecting P: from even being seem by admin mode (see below).
BUT BUT BUT, and one more huge BUT. Bis binarise is exceptionally fragile to 'garbage' on your p: drive of any flavour.
But, When making binarised wrps. It hunts every-single-folder on your drive: in a desperate hunt for land classes. It quite happily misinterprets badly named files, or cpp's with garbage, and crashes. (My tools prevent bis binarise from doing this search at all)
But, When making animated p3d's it will desperately hunt all model.cfgs in each parent\folder all the way back to drive:\ (and can crash on anything.anywhere on that drive)
But, When attempting to binarise a paramfile (rvmat eg), or convert tga/bmp/png to paa), it first looks at binmakerules.txt which often points to the wrong location. And, while not often, the convertor.exes themselves go awol with a drive:\ full of things-other than P:\Projects (p:\a3 eg, p:\MyProject eg). Again my tools block bis binarise from doing anything here at all. But, that ain't helpful if you're using Addon Maker.
The long and the short of all these BUTs is you should avoid having *anything* on P: other than projects. When binarise crashes it can't tell you why. Because it crashes! You are left with a completeley innocent project of yours that is not in error and have no chance in hell of discovering why your pbo-making has ended in flames. You can, for instance, make six p3ds and all is fine, despite the garbage, and the 7th fails because, unlike all the others, it uses a FireGeometry lod, or a lodNoShadow (given only as silly examples). Due to LodNoShadow, or a fireGeometry lod, or a wrp of 80k x 80k (all given as silly examples), bis binarise has wandered off into places it would not go otherwise.
You have no excuse, and no sane reason, to have any exes on that drive at all. To do so is to invite a crash and burn.
And finally, to answer your question about directory junctions. They are compatible. A folder (not a drive) simply exists in two places. One to satisfy binarising/editing. The other to satisfy ease of publishing perhaps, an svn or git from other 'projects' or, in my case using the exact same project\code for dayz, arma2, and arma3. Caveat: be aware of the but's above. A subst puts an entire drive in two places, a symlink cherry picks folders into two places.
One final comment about 'P:\ drives' in general. You should never, never, ever use admin mode (except of course for installing and setups). You are inviting any tool.exe to scribble over/ wipe out/ destroy all and any contents of at least that drive, if not all drives when they go bang,. You are inviting trojans, viruses and worms (often inserted into tool.exes), to party at your expense. In the specific case of a subst command, there are two p:\ drives, A: 'the user (you)' and B: Admin, who is a user just like you but with different (not better) privileges. One of these drives might not exist at all, might be the same, or might point to a completely different set of folders. C:\elephants vs C:\giraffes eg.
you can wipe out most causal faults (runaway exe, or trojan) by simply NEVER creating a subst P:\ drive in admin mode.