This is trivially implemented for the SPO or SPOC index if we constrain the choice of the separator key for index partition splits such that it does not split the statements for a given subject (this is not wise for the POS index, but is fine for SPO or SPOC).
The join will consist of the constraint to be satisfied (predicate and object constraints) plus a list of the additional predicates whose objects should be bound. The predicate position could be a variable in which case all predicates would be matched.
The original query would be rewritten to specify the star join for the attributes of some subject. When executed, the star join would override the join task on the shard. If the constraint is satisfied, then we can reposition the tuple cursor to the start of the subject (which will typically be on the same leaf) and then scan to pick up the desired predicate and value bindings. When a list of predicates is given, we could also advance the tuple cursor to each desired predicate in turn and then advance it to the start of the next possible subject when the last statement of interest was processed for that subject.
Unlike a normal join task, the star join can bind many variables in the object position at once. Optionals should be supported for predicates. When there is more than one attribute value for a given predicate, we need to output multiple solutions. The easiest way to do all this is to buffer the matched tuples and then generate and emit the necessary solutions.
This is a great place to start for pluggable join algorithms.