This is about a month late for the discussion, but...

First off, what little I know about booting MicrovaxIIs:
- If a TK50 tape has a raw executable binary (no exec header) written on
  it as the first file made up of 512 byte blocks, the "boot mua0"
  console command will load that file into memory and try to execute it.

- If a simple boot block structure is put in the first sector of a disk
  attached to a qbus mscp controller, then the system will load the
  sequential sectors specified by the boot block into memory and then
  boot it.

- The "boot xqa0" command invokes a DECnet/MOP bootstrap over the
  ethernet. (A DECnet mop boot server is straightforward, but works at
  the ethernet packet level normally responding to an ethernet multicast
  address packet. I am not sure if the BPF has sufficient functionality
  to permit building a server without kernel hacks to the ethernet
  driver or not?)

In general, given all the different vax hardware variants and the weird
removable media involved, I would suggest considering an approach that
requires a minimum of primary booting functionality. If a stripped
/genvmunix was prepended to a very small root fs using a memory file
system, then loading that one image into memory would be all that
would be required by the primary bootstrapping.

For the MicrovaxII, the console interface would provide all that is
required to load the image into memory using any removable media
supported (TK50, RX33, possibly RX50 although 400K isn't likely to
be large enough?). For an ethernet or console serial line download,
a relatively simple server would be all that is required.

As for routine booting off of disk, leaving an area at the beginning
of the disk for the stripped deheaded /vmunix could avoid the hassles
of writing a /boot and maintaining the various standalone drivers, etc.

Anyhow, hopefully this might be of some use, rick