You're just modelling the arguments to `svcadm`.  If we take your approach, we can't provide a list of services as you're forcing an instance name to be appended to each.  Sometimes we want to use an instance name, sometimes we don't.  The net result is always `svcadm <command> <FMRI> ...` where `<FMRI>` may be `<service>` or `<service>:<instance>`.  That's already written in stone in the command-line API.  Attempting to split that out actually reduces flexibility.

I don't see how this has anything to do with platform.  Here are some real examples:

```
svc:/network/dhcp/server:ipv4
svc:/network/dhcp/server:ipv6
svc:/network/nfs/client:default
svc:/network/ssh:default
svc:/network/ftp:default
svc:/network/routing/route:default
svc:/network/daytime:dgram
svc:/network/daytime:stream
svc:/network/inetd:default
svc:/network/ldap/server:openldap_24
svc:/network/ldap/client:default
```

Today, we might write `svcadm enable ssh` or `svcadm enable network/ssh` or `svcadm enable network/ssh:default` and they all mean the same thing.  `CAF::Service` shouldn't care, it's just an argument passed to the `svcadm` command.