If you actually bother to read the Federal Register text, you can see in the second paragraph of the introduction that the JOBS Act, and this subsequent regulatory structure, only applies to crowdfunding where the reward is a security. It specifically explains that this is different from the current model of crowdfunding in the U.S., where the donors receive some "token of value" related to the project, not a share of future financial returns. The SEC isn't trying to regulate the current system, but is trying (as directed by that law) to allow crowdfunding where the donor award is a security; the current regulatory structure, based on the Securities Act, largely makes this sort of model impossible due to the various requirements of public offerings.

So, there's nothing to get up in arms about. This is just a move by the SEC to allow something that isn't currently permissible under U.S. law, not an attempt to "tax Kickstarter" or "regulate Indiegogo" or whatever other nonsense people claim.

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.