I was just remembering that we discussed this a few days ago. This really does suck, and I hope you can find some work at Nexenta or Joyent/Samsung or one of the other businesses that help develop illumos. There's a page on the illumos wiki with links to job listings: https://wiki.illumos.org/display/illumos/illumos+Jobs.
Without confirming or denying anything, can you allude, vaguely, and super non-committally, that Oracle, who may or may not be your boss, cares about Solaris?
I'm not terribly familiar with the ZFS/DTrace side of things but Solaris 11.2 added Kernel Zones [1] and Solaris 11.3 added more features [2].
We have Unified Archives as a way to create either a golden image of a system (all configuration and other host-specific data) or a "clone" image (the software payload minus host-specific data) which can be used to install metal, LDOMs, kernel zones, or branded zones and allow P2P, V2V, P2V, or V2P. [3]
We've had Boot Environments since 11.0 [4] which allows me infinite flexibility to upgrade or even try out random things. If things go south, I can roll back to a safe BE in 30 seconds with no issue.
Unified archives sound like an extension of flash archives, available since Solaris 9. Boot environments showed up in the post Solaris 10 open source effort, again, pre Oracle...
FWIW, I am a Solaris developer on the zones team and was part of the project team that implemented unified archives. I joined the Solaris org about a year before Solaris 11 shipped and was a Solaris admin for a long while before that. Here's my take.
Flash archives were available long before Solaris 9 - I think it was Solaris 7. In the Solaris 2.5.1 days I invented something similar for use in in the academic labs I managed. Boot environments were introduced with Live Upgrade which also was available at least as far back as Solaris 8. Lessons were learned.
With Live Upgrade, the admin had to plan ahead to ensure that spare disks or slices were available to create an alternate BE. Most admins didn't have the foresight. Then when it came time to patch or install/remove software, the pre/post install scripts often had broken logic that caused changes to happen in the wrong place (or not happen at all). Live Upgrade came long before zones and was an extremely poor fit. Live Upgrade came out of an org other than the Solaris org, and the lack of coordination was quite evident.
Flash archives seem to have a design point of installing one system to look exactly like others. Installing an Ultra 5 from a flash archive created from an Ultra 10 was considered going off the rails. In reality, this worked most of the time. When I used flash archives extensively, I would tend to create them on 15k or 25k domain and use them on all systems. Again, flash archives were conceived long before zones and integrated poorly with them.
The release of Solaris 11 integrated lots of stuff that was previously cobbled together. ZFS is the only supported root file system and zones also live on ZFS. Boot environments are required on the global zone and in zones. There were rules as to where the zonepath could be, making it possible to always come to a correct solution as to how to create a new zone boot environment that corresponds with the global zone boot environment. This foundation works nice with the packaging system, IPS. IPS determines whether you are changing files that will require a reboot. If so, it creates a new boot environment via zfs clones and updates the new boot environment. When you are ready, you can reboot into the new boot environment. By choosing defaults, you get the best practice. The system actively prevents you from doing things that will cause support to say "back up, repartition, and restore." That's a big improvement.
Unified archives build on lessons leared from flash archives. Flash archives were really only intended for system cloning, but the archive contained the configuration from the master system. Unconfiguration happened as part of deployment, not as part of archiving. Unified archives integrate with the packaging system to revert various amounts of configuration (in a temporary boot environment) so that the archive is optionally unconfigured and always ready to be moved to a new virtual or physical platform. Transforms between zones and global zones are explicitly supported. Want to convert your ldom/zone/kernel zone/whatever to a whatever/ldom/kernel zone/zone? That's supported.
Unified archives come in clone and recovery variants. A recovery archive is suitable for bare-metal restore and preserves all of the configuration (networking, name service config, etc.). A clone archive whacks all of that configuration and ensures that it is not part of the archive.
Unified archives allow multiple virtual systems to be included in one archive. This means that you can type "archiveadm create myarchive.uar" and it will create an archive that has the global zone and all other zones, each of which is individually installable from the archive.
Unified archives allow inclusion of multiple zpools in the archive. In contrast, flash archives only archived the root pool. The selection of which pools and/or datasets is possible via command line arguments.
I seem to recall that after I used a JumpStart server to put a flash archive on a system, I would do a "reconfiguration boot" to have the kernel probe all the devices again and rebuild the device tree. "touch /reconfigure && reboot" I think?
I would do this with similar but not exact systems, like you mentioned - the 5 and 10 were similar but not the same...
Jumpstart should have put the /reconfigure in place so you wouldn't need to. But that only adds new devices, it doesn't deal with old devices that have gone away. This can lead to things like a root disk being on c0 on one system and c1 on another, and similar confusing numbering for NICs. Experience tells me that this is less problematic than many inside the Solaris org have suggested.
Network virtualization was barely integrated before Indiana got cut off.. Only Oracle has the infrastructure and customers necessary to find and fix the less obvious bugs there.. But I wouldn't use code owned by Oracle.
Porting what is good into BSDs is really a better idea than trying to keep anything Solaris based going. There are people I respect that I wish would realize that, but I don't think it would be fruitful if they heard it from me..
"Your Model Y Production is expected to begin late next year"