Tippis

Short answer, you're asking too much.
The built-in tasks work ok… ish… for two specific scenarios:
You want some background/decorative activity on an airbase while the player gets started up in their aircraft. You want to run a very brief helo transport mission where troops run up to you and jump in, and then you dump them somewhere — end of mission. The problem is that both the helo's load and the ground units' embark tasks only work on the first waypoint. As in, it's the first thing they do as soon as they go active. They can unload/disembark at later stages (although, for the ground units, that will always be waypoint 2 since they obviously can't do anything while loaded in the helo). But that's it. Like many special waypoint actions, they were made once upon a time to do a single thing, and have never been revisited as the game has grown and added more units or more helos or more situations that you can create with other functions added to the game (see, for example, everything involving AI JTAC).
What you want can be done, but you'll need to go the scripting route and find a framework or package that is tailored to your needs, with the scripting telling the units what to do and when rather than the built-in waypoint actions. I've long since lost track of what works best since others have been doing the heavy lifting on the helo mission creation side, but back in my day, CTLD was the go-to option for most of that stuff. No guarantees as to whether it still works or is sensible any more. 😛

It's not the only solution, but it's the most immediately available. Depending on what other restrictions you have to adhere to, it might also be the one that saves you the most time. If it's mostly scripts you want to load, you can look up “dynamic script loading” as a topic all in and of itself, and what kind of setup is required to make that happen. Scripting in general can let you work around many of the annoyances in the mission editor, but the complexity will soon require you to set up a full on script debugging environment to make all of that work without turning your hear grey.
Part of that should probably be to figure out what you actually need those triggers for, and if they are such a necessity that you need them in every mission you create. Some organisation and optimisation might cull a few from the list.
And if it's only the triggers and their attached assets we're talking about, it's utterly trivial to transfer those from one terrain to the other — you just have to change the definition in the mission file of what terrain it is supposed to use. So you only have to do it once, and then change two lines of code for every other terrain you want to use.

Yes, but it's a functionality built into Windows via links and junctions (and in this instance, junctions in particular) rather than something DCS or its installer can be made to do.
The tricky part is that, unless you know beforehand exactly what specific directories in the DCS install will be called, you can't prep them for the install and update, and instead, you have to let them install normally, move a particularly resource-hogging directory to a better location, and then link to it using its proper name. This little song and dance, then, will need to be performed every time you install something new that you don't yet know where it will be placed or what it will be called. So between the install and the final move and relinking of the directory, you're still going to need that free storage space (although it's entirely possible that you can make that a bit less resource intensive as well by moving and linking in the download directory that the updater creates).
So, basically:
Let the thing install. Move the offending directory to a more pleasant location. Use the mklink command(s) as shown in the article above to link the moved directory back into its original position. Hopefully, DCS will be none the wiser, especially not if junctions are used.

No.

I'm a glutton for pain and bugs and fancy new things (and also running servers for people with the same proclivities), so for me, there's little other option. 😄 
 
That said, my experience is that there's very little benefit to running the stable branch to begin with. It may be “stable”, but commonly  not to a degree that separates it from the beta branch in any appreciable way, and the beta branch will have the latest bug fixes, which is often worth more.