Now for the second question:
Some questions are:
1) Do we want to support separate roles for application level security vs administrative security?
2) If we do, can support for this be deferred to a subsequent iteration of this feature?
3) If we do, what changes are required to the underlying AS to allow a meaningful separation of the roles?
If we want to have a god-like role, then any "split" can be deferred from this iteration. We add the god-like role for this first iteration, and then in a later iteration we add a new role with only application level security permissions. Possibly we could add a 3rd with only administrative security permissions, if that was a valid use case.
A twist on this is the "Auditor" role notion. An Auditor role is someone with read-only access to everything, but is the only person with access to the administrative audit resources. This approach ensures that a god-like administrator still has someone to watch over him/her.
I don't think having an Auditor role either now or in the future precludes having an otherwise god-like Administrator role in the first iteration.