Didn’t you say that at least the subject will be a sequential identifier, though, and so not susceptible to that optimisation?

How many actual indexes will you need to efficiently support that set of queries, given your heirarchial index structure? Only 3?

The latter. Subject identifiers aren’t exposed to the client so there’s no way to make statements using them specificially. Instead to join data from two subjects in different graphs you must use identity by discription (i.e. the subject that has these property values..) and the person/agent doing the query must know about them.
Internally the subject IDs can be in the ‘object’ position to support things like containment. E.g. the XML:

<person>
  <name>Phil Dawes</name>
  <email>phil@example.com</email>
  <knows>
     <person>
         <name>Steve</name>
         <email>s@example.com</email>
     </person>
  </knows>
</person>

Internally indexed as:

#1 name "Phil Dawes"
#1 tag Person
#1 knows #2
#2 name Steve
#2 email steve@example.com
#2 tag Person

but externally you can’t refer to them. Does that make sense?

Opaque subject identifiers are even easier to index because they can be picked to be sequential in the index. I.e. subject 3 is at position 3.

Re. number of indexes: I think I’ll need at least the following.

s->p->o
p->o->s
o->s->p

So 3 index hierarchies for searches. The subject-id-in-the-object-position mentioned above is a special case, and will probably require its own (relatively small) index o->sp.