You have programmers. You have multiple projects. They might be working offline. For this, you really need a Distributed Source Control system such as git or mercurial. I personally recommend mercurial as it's got good Windows tools (TortoiseHg and HgScc for Visual Studio integration). You can put your "pure" repository on your share, then have the programmers push to it -- or, better yet, have an "incoming" for each project to which anyone can push, then a "pure" to which only project leads have write access and into which they can push approved versions.

If, for some reason, you simply can't run source control, Windows offers Offline Files functionality that can sync individual folders if you set them up correctly. What this means is that you need to ditch this "shared drive" concept and set up your file shares correctly -- by which I mean having multiple shares, one for each project. Users then connect to the share in question and choose to make it offline, or you create drive maps and enforce offline files using group policy.

Actually, as the people who found the first RT jailbreak noticed, the only thing keeping Windows RT from running ARM compiled applications (which you can create in Visual Studio, even!) is a policy that mandates that only Microsoft-signed executables can run outside of the WinRT environment. If Microsoft removed that restriction by changing a single registry key, all of that compatibility would suddenly appear. In fact, .NET apps distributed in PE form and compiled for Any CPU would be able to run without being recompiled at all.

Yes. Turn off Secure Boot in the UEFI firmware menu (accessed through Advanced Startup), then boot off the USB Linux boot device of your choice. I expect a modern distribution of Linux will have drivers for most of the hardware inside the Pro. Alternatively, run it in Hyper-V (or VMware, or VirtualBox, or the hypervisor of your choice), since it's an x86 Windows 8 device with hardware virtualization support.

Only the RT has the "permanently locked" Secure Boot setting. The Pro is a full-fledged i5 device that can run Linux just fine.

In .NET, you exactly have the same thing: ObsoleteAttribute. It's not often used, but it does exist.

No. Windows handles DST rules in the registry, so it's perfectly capable of date-dependent DST rule handling. The article discusses those recommendations as a way to avoid problems caused by issues with Outlook and Exchange 2003, both of which have their own unique ways of handling TZ changes (basically, they fail to store TZ information with dates, so TZ changes screw up the display of appointments). The problems were largely addressed in Outlook and Exchange 2007 and completely fixed in the 2010 versions, which keep the appointments in GMT-plus-offset format.

There's legitimate complaints you can have with the way Windows handles TZ changes -- personally, I'm not a fan of having to install TZ patches from Windows Update and I really dislike how Windows keeps the RTC in local time instead of GMT -- but don't blame it for the failings of antiquated and soon unsupported Office programs.

Honestly, I've not found that to be the case. In most cases, you can disable the integration drivers in the guest, then move the VM to the new virtualization platform and start it back up. You may need to do a startup repair or in-place upgrade on an older version of Windows; Windows 7 (2008 R2) and 8 (2012), however, are fairly resilient.

The smoothest way to do it, though, if you've got the time, is to use the new platform's P2V tool to create a new virtualized VM based on the old one. This is how I've moved guests from Virtual Iron and Oracle VM to Hyper-V. In general, I'd say this is probably the smoothest way to move a VM running any OS to any other hypervisor, as it gives you a backup copy on the old hypervisor if needed and ensures that any special drivers are injected for the first startup.