Just a few small remarks:
Semantically, for the actor ID, shouldn’t it just be the “authority-part” of the DID, rather than having a /actor path added? The base DID itself should be resolvable to a DID document that represents the DID identity, and it’s kind of like a catch-22 if you have objects that are grouped under the DID, where the identity itself is grouped under the DID. It also adds ambiguity, unless everyone must explicitly use /actor for the actor object.
As for swapping did:apkey to did:ap:key, and using did:ap like a general namespace: I’m not sure if that’ll cause confusion when officially submitting the DID method for inclusion in the DID method registry, given did:ap wouldn’t be a complete DID method itself, and I don’t know if there are any accepted entries that treat the top-level as a generic namespace for “submethods” instead.
And as I mentioned in the other thread: it might not be worth distinguishing a did:ap counterpart for did:web, as just another application route can be added to handle application/did+ld+json which might possibly be able to even return the same content.