Jaga

There's plugin development information available for Drivepool on the Development Wiki - creating your own to do what you want seems the more direct route.  Additionally the Drivepool Command Line utility is packaged with the standard distribution, you can call it with dpcmd.exe and run a brief list of commands with it.
I haven't seen any mention of an API, but that doesn't mean one may not exist.  Alex and Christopher are working on new things all the time.  Creation of a custom plugin to do what you want might also benefit others, and integrate seamlessly with Drivepool.

If you're going that route, you'll want to consider your old pool architecture (how many drives, what size, etc) compared to the new one.  If you have the same number of drives, the migration still isn't too hard:
Deactivate the licenses, uninstall the software Share each hidden Poolpart-xxxxx folder (from each of the old pool's drives) on the network  (i.e. OldPool-E, OldPool-F, etc) Install Drivepool on the new machine, create a new pool using your new drives, then stop the Drivepool service (optional). Access each network drive-share you created on the old machine, and copy it's contents into each hidden Poolpart-xxxxx folder in the new pool.  Each drive in the Pool has one on it. Start up Drivepool on the new machine (restart the service first if you stopped it), and tell it to re-measure the pool so it can see all the content you copied in. If you have a different number of drives, that's okay too.  You'll have to copy the files from the old network drive-shares into the new Poolpart-xxxxx folders on each new drive, and then re-measure (first) and re-balance (second) on the new machine.  If your new drives are large enough, you can copy multiple old Poolpart-xxxxx folder contents into the same Poolpart-xxxx folder on the new pool.
Basically you are manually populating the new pool's drives with the old files via network copy, then telling Drivepool to "go see what's there" (re-measure), and "spread it all out evenly" (re-balance).  You may want to use the Disk Space Equalizer plugin for Drivepool, to evenly spread out the newly copied files in the new pool.  Install it, open Drivepool, toggle the plugin on once, let it run, then toggle it off.
It won't matter if Drivepool/Scanner are deactivated/uninstalled on the old machine, since all you're doing is manually accessing the hidden Poolpart-xxxxx folder that it leaves on all pooled drives.  DP doesn't need to be running, activated, or even installed on the old machine for that, just the new one.
One thing of note:  to keep the same folder structure your old pool had, you want to copy the folders/files from inside the old Poolpart-xxxxx folders exactly as they were.  If you put files or folders into different locations from where they used to be, the pool won't look the same.  The exception of course is copying two drives' worth of Poolpart-xxxxx contents into just one Poolpart-xxxxx on a new pool drive.  The folder/file hierarchy inside the hidden Poolpart folders is important.

You can shut the system down, physically remove the drive, then boot up and remove the drive from the pool.  At the point where the drive is "missing", Drivepool should stop trying to access it, which is what I suspect is giving you problems.  It won't affect the other drives in the pool or the data on them.
https://stablebit.com/Support/DrivePool/2.X/Manual?Section=Removing a Drive from the Pool
Scroll down to "Removing Damaged Drives".

Have you tried setting them to Automatic (Delayed Start)?  Might help if there are any timing issues.
Also - is service Recovery set to auto-restart in the event of service failure?

Using a defragmenter on the drives in the pool won't hurt anything - Drivepool doesn't care where on the disks the files reside.  But letting a drive get to 0 bytes available can be a real issue for Windows (it doesn't like it one bit).
Due to your space issues and different drive sizes, you should probably enable and use the "Prevent Drive Overfill" plugin in Drivepool.  You can get there by clicking the up arrow next to Manage Pool, then "Balancing...", then the Balancers Tab.  Find the plugin in the list and enable it, and try to set a reasonable "max full percentage" on the drives based on how much free space you have left (total).  Then move it up the order with the up arrow on the right so it's near the top.  You'll have to kick off a manual re-balance for it to take effect (usually turning on the balance immediately switch works).  If it doesn't kick off straight away, do a re-measure on the pool and it should.
The SSD plugin really only helps with speeding up pool write speeds, and it will migrate files that land on the SSD to the regular pool disks so they don't stay there.  It's not considered permanent pool storage, unless the rest of the pool is completely full, in which case it would (reluctantly) continue to hold the files it stored.
 

That should work just fine.  DrivePool isn't reliant on the OS version.  As long as it sees the hidden PoolPart folders on connected drives at boot/startup, it'll remount the pool without issue.
Be sure to contact CoveCube support and ask them to deactivate the license you had issued DrivePool on that computer, or you won't be able to re-activate using it.
I haven't used Veeam (yet), though I evaluated it last week after reading more positive comments elsewhere on it.  I'm currently using Macrium Reflect, which (for servers) has a rather heavy expense associated.  I'll probably end up using Veeam on my new WSE 2016 server upgrade.

There are many ways to accomplish it, using either 1 or 2 copies of DrivePool.  2 DrivePool installations makes things a bit smoother overall.  Here are two ways I'd envision setting it up:
 
First solution (2 copies of DrivePool, 1 copy of Cloud Drive):
Server A: Pool 1 (local resources) Server B: Pool 2 (local resources) - Pool drive shared to Server A Either Server: Pool 3 (Gdrive resource via Cloud Drive) Whichever server manages Gdrive via Cloud Drive, create your Top-Tier Pool there (using Hierarchical pooling) consisting of Pools 1/2/3 and share back to network. The machine using Cloud Drive will control all duplication via DP on the top-tier pool.  Both machines would share duplication workload.  
Second Solution (1 copy of DrivePool, 1 copy of Cloud Drive):
Server A: Pool 1 (local resources) Server B: share storage space to Server A via network Server A: Pool 2 (network storage space) - Pool is built either using drive mappings from Server B, or via Cloud Drive's File Sharing feature (where Cloud Drive creates a Drive on the network resource and mounts a letter for it locally) Server A: Pool 3 (Gdrive resource via Cloud Drive) Server A in this case would contain all sub-pools, and the top-tier Hierarchical pool for sharing back to the network.  It would control all duplication, and have virtually all of the workload. Server B in this case is just a resource for space.  
The cleanest and best balanced implementation would be the first, though it requires 2 copies of DrivePool.
 
There are three ways to handle drive mappings for Pools across the network:
iSCSI drive mappings are faster than other methods and have no overhead, but not very flexible. Mounted network folder shares are easy to setup, slower than iSCSI, but faster than Cloud Drive's File Sharing. Cloud Drive's File Sharing, which allows you to control space used on the target resource.  Slower than other methods, highly flexible.  
@Christopher (Drashna) - do we have a way for multiple networked installations of DrivePool to see each other's Pools and include them as children in higher tier Pools, *without* first mapping drive letters for them?  Seamless interoperability across the network would be a nice feature for server clusters, and help cut down on drives/letters.