Hey Pete, I had the same thought. Since I didn’t mind didn’t mind reformatting the machine, I figured I’d experiment with it.
TL;DR: Things did…not work out as expected, but I do have a working installation now 
The backstory is, I had a Windows 10/Arch dual boot setup across a number of drives. Arch piggybacks off the EFI system partition created during Windows 10 installation since Windows is pretty stubborn about its disk topology. This was mounted at /boot/efi, with grub and windows efi entries living in their respective directories under $esp/EFI. I setup custom boot entries in /etc/grub.d/40_custom for Windows, and ran grub-mkconfig -o /boot/efi/grub/grub.cfg. There was no os-prober involved.
Now, I wanted to basically replace my Arch installation with Ubuntu Mate, arriving at a Windows 10/Ubu dual boot instead. I was nervous Ubuntu would somehow corrupt my boot with it’s own opinionated layout, so I wanted to own that part of the installation and reuse my well understood boot setup.
I entered the UM installer, pointed it to my root and home partitions. It found the ESP and marked it the Windows System Partition, no indication that grub also lived there. I changed to to “do nothing with this partition”. Then, for the bootloader location, I chose a random partition I created on a flash drive [1]. Install goes through without a hitch and I start to inspect what the installer actually did…
The syslog reported successfully installing grub to the dummy flash partition despite there being nothing in the partition at all. A new directory was installed to $esp/EFI/ubuntu despite me explicitly telling the installer to ignore the partition. It contains a number of .efi entries plus a grub.cfg pointing grub to /boot/grub which is actually on my root partition and contains the real grub.cfg. os-prober indeed picked up on the Windows install, adding a Windows entry to the ubuntu grub menu. /boot contains everything you’d expect, with an efi mountpoint that ubiquity decided to use as the $esp mountpoint, evidenced by the fstab entry. My existing grub install inside $esp was not touched!
In summary, I clumsily arrived at what I set out to do with some confusing behavior along the way. My system now has 2 different grub efi entries, the original, and the Ubuntu one. I can boot Windows and Ubuntu from either! (Sidenote: I manually added an Ubuntu entry to the original grub.cfg to make this happen). To clean it up, I’ll delete the original grub efi entry + install files since it’s entirely redundant at this point. Still some lingering questions:
[1] What the hell is the installer actually doing when you give it a bootloader location? Why do I have the option to choose a partition /dev/sdx1 or the device itself /dev/sdx, and what does it do differently in either case? (I suspect this is related to legacy BIOS boot?). That seems like a great way to render an existing system totally unbootable!
[2] I bumbled my way through this and would never suggest it for a system I wasn’t ready to nuke & pave. Is there a supported way to take lower level control of an install, perhaps via command line tools and chroot? If not, is there any interest? I would be happy to do some more research on this and document the process.
