This is now incorrect example as it was previously showing how to include /usr in BE and skip the nested /usr/home. You could use something created by default by the installer here instead, e.g. /usr/ports or /usr/src.

zroot/home is created by default by the installer now. It is not nested under /usr. but is under /. However, I see what you mean about the nesting. Maybe /usr/ports should be added as an example too, and used in this description.

btw, zroot/var now has can mount off in the default setup, which seems correct, so this part of the example is out of date.

I have to go with Yuri on this one -- the example doesn't have the same meaning with zroot/home, it should be swapped out for zroot/usr/src instead (removing references to home entirely) if we're going to touch it. It doesn't quite make sense in this context to have both zroot/home and zroot/usr/src as examples.

I'll use zroot/usr/src. But why do you say it doesn't make sense to include zroot/home as an example as well? It seems like the prototypical example of something that should not be in the boot environment. It isn't nested in the same way, but that's not all this example shows (e.g. /var).

Because this part is specifically about guiding one to navigate the intricacies of subordinate datasets, how to understand when a second-level dataset may or may not be included by tracing from the root of the pool out to it and examining canmount along the way. One should be able to extrapolate from that to any given scenario, since it's the moderately more complex scenario to work through.

Then why is zroot/var there? And should I change canmount for var to off? Or delete it?

I was trying to keep it simple while still realistically representing a theoretical whole system. You can keep zroot/home in that listing (sorted above zroot/usr, though), it's just this reference and the next that should be zroot/usr/src (and zroot/usr/src added in the listing above with canmount=on).