It’s nice to be proven wrong so quickly 
@brettcannon came up with the idea of an explicit mechanism for dependency lists to reference each other for inclusion / extension (rather than having any pre-defined relationships between them, as in my proposal).
I should clarify here (from the discussion of extant uses of requirements.txt that, while locking installers might see a requirements.txt with only “root” dependencies as input that’s specifically oriented towards making a lockfile, that’s still fundamentally just an “alternate list of dependencies”. In principle, any list of dependencies can be solved for, and any solution can be locked.