Upgrading manifests is very complicated, error prone, and doesn't match user expectations (administrators or developers).
Administrators wish to make the same SCF customizations on multiple machines.
For problem 1, restructure the repository into a log. Developer defaults in service manifests can go into a base profile, and administrative customizations can go into a local profile. Manifests can be upgraded by replacing their section of base.
For problem 2, extend the profile file format to customize arbitrary properties.
Administrators and developers expect uncustomized properties to track developer deliveries. Certain implementation choices (employing the easiest upgrade algorithm, loading the platform.xml and generic.xml profiles into local) will prevent this for some properties by creating false customizations. Not providing an interface for administrators to observe and remove customizations will deprive users of recourse.
After customizing a property, an administrator may wish to remove the customization so that the property will track developer deliveries in future upgrades.
Choose the cheapest options: Implement the easy upgrade algorithm, load all profiles into local, and don't provide an interface for administrators to observe or remove customizations.
After an upgrade, the easy upgrade algorithm will mistakenly create customizations for uncustomized general/enabled properties and will mistakenly omit customizations for properties other than general/enabled that have been customized-to-same. Neither is very surprising since they are similar to today's behavior.
After an initial install, the manifest-import service will apply platform.xml, generic.xml, name_service.xml, and site.xml. These will result in customizations for general/enabled (and perhaps other properties) on services they affect. This is correct for site.xml, and can be considered correct for generic.xml, though in the long-term administrators will be advised to remove these customizations from local in favor of the system-defined profile(s).
After upgrade or initial install, newly installed services will have the customization behavior we desire in long-term, except the only way to remove a customization will be to delete and reimport the service. This will be inconsistent with pre-existing services (with customizations for general/enabled) which I think will frustrate administrators. Using netservices will also reapply generic.xml, which might create customizations that should be removed from local after upgrade to phase 2.
I think the worst problem with this solution is that fresh install will result in customizations that have to be removed after upgrade to phase 2, whereas if we placed the profiles into their own repository profiles right away, this would not be necessary.
As in solution 1, except make manifest-import and netservices load the platform and generic profiles into separate repository profiles using a private svccfg interface. Don't update them after they've been applied, however.
After an initial install, properties will only be customized when the administrator modifies them or service-specific code uses an administrative interface (e.g., svcadm enable). The only way to remove a customization would be to delete and reimport the service, again.
The end result is like solution 1, except administrators should have fewer customizations to evaluate after installing phase 1 and upgrading to phase 2. The customizations after an upgrade to phase 1 will keep netservices from operating properly, however. And I think the inability to observe customizations and the inconsistency between newly installed services and upgraded services is enough of a problem to keep looking for a solution.
As in solution 2, except update the platform and generic profiles on each boot. This would mean that services installed during the upgrade to phase 1 or later would be subject to profile updates. This is closer to what we want in the long-run, but the inconsistency with services from an upgrade would be undesirable. It's not exactly what we want in the long-run because the profiles would not be updated on packaging operations.
As in solution 2, except provide an interface for administrators to observe and remove customizations. Place platform and generic profiles into their own repository profiles, and don't update them after creation.
After upgrade to phase 1, administrators should evaluate the overrides generated by the upgrade algorithm. This should minimize unexpected upgrade behavior.
Employ a heuristic upgrade algorithm which can reduce, but not eliminate, the number of false customizations during the upgrade to phase 1. It seems like a substantial amount of work, though.
A combination of solutions 4 and 5 would be best. If solution 5 will significantly delay delivery, though, it can be left out initially and delivered later.