I am not sure what you mean by "fresh Ubuntu 16.04 instance on Windows 10".

do you mean you used Ubuntu app from the Windows store?
You used virtualbox / vmware / hyper-v virtualisation on Windows?

I understand that windows 10 itself is running in a virtualbox machine, on top of Mac OS. But I need to also understand which virtualisation technology is used to perform the nesting to do the jump from Windows to Ubuntu.

However, I'm trying to make it easier for Windows 10 users to compile the Bitcoin Core application from source. This is currently problematic with Ubuntu 16, so I'm trying to see if it can be made to work with Ubuntu 18 (at least once that's ready). Since I don't have a dedicated Windows machine, I'm running Windows in a VM. I don't mind breaking it.

Where can I track progress for (experimental) Ubuntu 18.04 support for the Ubuntu app on Windows?

You do not need windows at all to cross-compile..... the instruction
is to use cross-compilation on Ubuntu, to generate binaries that you
can use on Windows.
(They choose to use Ubuntu WSL, because they assume the host machine
is windows instead of Mac OS X, but you already have virtualbox so
install Ubuntu there)

You can use Ubuntu in a VirtualBox on MacOSX to do the cross
compilation, copy the binaries out of that VM, into the Windows 10 VM
to use them.

Or you could install mingw-w64 toolchain on mac os x -> e.g. using Homebrew.

You simply need *nix like environment with a mingw-w64 toolchain, of
which any Ubuntu or Homebrew should do.

Also they never ask you to _upgrade_ to 18.04, you should be able to
simply use the Ubuntu WSL app directly, without upgrading it to a new
release.

I know I don’t need Windows to compile for Windows, but I’m writing / updating those instructions for Windows users. Currently the Ubuntu 16 instructions tell the user to add sources from a newer release, which could cause problems.

I've gotten the release to upgrade to 18.04 on WSL, the issue I'm running into however is that systemd will not reinstall. TBH WSL does not require systemd to operate, but it defiantly makes the system angry if it can't setup a way to manage startup. Just for anyone reading this via google, if you want to push your WSL build to 18.04, DON'T. For those of you who are ignoring my warning, you can push it to 18.04 BUT YOU MUST HOLD SYSTEMD. If you try to run an upgrade and allow systemd to be upgraded the upgrade will fail and you will be left with a completely borked system. My thoughts at the moment is to try and grab a 16.04 systemd package and use that until we get a stable 18.04 one.

Update for you all. I forced systemd down to the 16.04 version, reconfigured it and it was happy. As for upgrading it to the 18.04 version, YOU MUST PURGE THE ENTIRE /usr/lib/tempfiles.d/ DIRECTORY. One I did that, even thought the install will fail, I was able to get systemd reconfigured. It now properly responds to dpkg --configure commands and the system is no longer in a broken state.

As for how to resolve this upstream, I have a felling this has to do with how WSL handles systemd (as, it doesn't, because WSL ignores systemd for the most part.) most likely related to the fact that we're not working with kernels, and systemd doesn't have anything to hook into during the upgrade.

If you're having trouble with a system you forced to the 18.04 beta let me know as I'm going to write a script here in a second to resolve the issue for you.