You meant PAD2, not second label?
Well, there are many possibilities. Firstly, the original (current) fbsd implementation is using exactly the scenario you did describe - info on the first disk, first label (PAD2). However, there are some things to think about - what if somehow this first disk was disconnected and reconnected later. What if the update by early boot program fails? Which disk is first one - bios systems reorder boot disks in many systems, depending on where you boot from).
Just as an idea (it does not have to be this way, but just as reference idea): We do not know which disk is the first one, so if we boot from one or another disk (I do it fairly often to verify things), which leaf vdev should I probe? I thought, ok, lets record it on every label of every vdev of boot pool - so whatever we use as "first" disk, it does not matter. Therefore, if the disk is readable, it should have all label instances with this config data. Now if we reset the data, what if one write will go ok, and others not? So, the natural idea is - if there is one empty PAD2, we fail back to normal bootfs property. For completeness, it would also mean that on kernel startup, the boot pool PAD2 areas should be wiped - for case the bootloader did fail all writes.
The PAD2 itself is just one of the currently safe areas. Note we can not use PAD1, or at least, we can not use first sector (512B from pad1) as it is reserved for partition boot block (and used as such for BIOS systems). Actually, if we keep in mind the sparc, pad1 is entirely used there - vtoc + first part of the boot program. Ok, in fact, we even could leave first label out for good and do not touch it at all. But we also do not have much more left except the tail of the boot area (3.5MB). So we could use it, but, there is obvoious risk as well.
So I would take this implementation as reference, proof of concept, and something to start from. Note, this very instance does not actually scan all 4 labels from vdev yet, as I did realize only during the writing, the loader is slacking there, so the label read update is in separate update, and after it is in place, we have tools to read all 4 labels.
Another possible idea is to not use disk at all and rely on, say, uefi variables, but that will limit target audience and will push whole idea into future.
And finally, we could invent yet another area - for example the reserved partition on GPT, but reserved partition is already in use for device id (usable or not), and reserved partition also may not be there...

I did mean PAD2, my mistake.
I agree that storing it on only one disk is a poor idea; and besides, if you use pad2 on one disk, you might as well use it on all of them, because once it's in use for one purpose, using it for a different purpose on only some devices would be much trickier. I was mostly trying to think of other locations we could store it, like reserved partitions.  Probably this is the best spot we have available.  The only other thing I would consider, in that case, is allocating only part of the 8k region to the nextboot config info; I don't think we expect it to be very large, and it might be useful to save most of the space to store other things later on.  Deciding on a maximum length for something like this is easier to do early, rather than late.

Did update the comment and added check for pad2 content from different labels.
Yes, the idea is that for nextboot to be used, we need to have the same non-empty nextboot string from all (healthy) disks. This is because the unsetting the next boot may have been interrupted in between updates, leaving some pad2's with unset command, and some with command.
Additionally, we need to require all pads to have the same command string, otherwise we do not know which one is to be preferred...
Also note this version is only reading the first label from vdev (label 0), as during the write I did figure there is no code to read all the labels, and so this code will be needing the update once the https://www.illumos.org/rb/r/250/ will land.

Yea, its leftover before I figured to set it as zio private in zio_root()

The idea is that from this write we should only get physical IO errors, and if lucky, we get the disk ending up in error state, but we still have good writes as well. Now while reading nextboot data, the errored disks will be ignored, the IO error should also get ignored and we have read from "good" label(s).
Now also on boot, we at least do attempt to zero out the nextboot, so even if we get something bad while reading, we still will get chance to boot without nextboot setting. And if all will go bad, there is an option for user to get to boot2: prompt and enter boot dataset manually.
Of course the alternative would just be to error out on whatever error we had there and therefore disable the feature. Basically it is decison point there, which way we should go - either to be opportunistic and try or to be more conservative and deny the feature on any errors.