See: Locators and older Locations
Identifying objects is one of the hard parts of computer science. xblocks has some ideas about identity based on what facets of the xblock you're querying: the student, the block's definition in the abstract, or the block in the context of a specific course. But, there are other aspects and other things to identify, and even the existing block aspects are imprecise. The other unaddressed aspects include what version or variant of the course you're addressing and what type of access you should have (exposure of instructor-only aspects, exposure of configuration, summary-only, guest-access).
The other identifiable objects include re-usable instructional components which are used by many courses, the notion of a course as something that was run for a particular set of students even if its content changed over that period (e.g., the fall university Y organic chemistry course), the notion of a course as it existed for a particular population at a particular point in time (e.g., that organic chemistry course before the instructor fixed the answer to problem 4 in quiz 2), the notion of a course as an expression of a related set of material which may have many offerings and change dramatically over time but would be still recognized as the same "course" (e.g., that organic chemistry course over all semesters), the notion of a sequence of such abstract courses with a dependency graph and possible set of gates (e.g., a chemistry major requirements sequence), and the notion of a "course" as a set of independently authored sequences of material with only superficial overlap but which teaches what we'd recognize as the same underlying concepts or material (e.g., organic chemistry as expressed by faculty at dozens of universities).
Anyway, back to versions and variants of blocks. Within a particular professor's semester-specific "course", there's still a fairly rich lifecycle. In the beginning, all of the material may be hidden from public in a draft form where the staff is updating individual blocks frequently. Each update creates a new version of the block. Talking about the block as it existed before the last set of changes is talking about a different thing than the block as it exists today, and yet, it's the same thing. At some point in the course's lifecycle, the staff may decide to release parts of the course as an alpha test to a select group of people. This alpha would be a variant. Any particular block in the alpha may be identical to the "same" block in the draft. At some point, the staff may update some of the draft blocks without updating the alpha. Now some refer to the same version and some don't although neither refer to the same variant.
xblocks has no way to express these notions of version and variant, but the SplitMongoModulestore adds these notions. Split is a constantly versioning system which tries to infer the staff's intent as the staff makes changes: do they intend to change all variants? do they intend to update a specific variant to reference this change? In split, variants are called branches.
Split also specifically addresses a "course" as a dynamically changing set of blocks intended for a specific population at a particular point in time (e.g., the fall university Y organic chemistry course). Addressing of a block is done by asking for the block by its id within a specific variant of one of those "course"s.