props: Atom.PropList
All structure-specific data is stored as Structure "properties", e.g. the argument Domains of a Domain constructor, the "underlying" Domain of a View, etc. Thus we replace dereferencing of REF Structure-specific record types by property list extraction We use Atom.PropList, not RefTab, since # props expected small.
Domains and Categories may also have true "properties", e.g. a Category's axioms, or the assertion that a Domain is of a certain kind which we have chosen not to make a Category, e.g. Dedekind Domains, Permutation Groups.
The Impl of a Structure will contain (public) selector procs for the expected items of info on props, for convenient access even within that Impl, and of course as the basis for public selector methods.
(Or should such selectors, and indeed all ops on a Domain itself, reside in the methods of some suitable Category? Perhaps such an op can be a method both in the Domain and in the Category, the Domain knowing that it's a (reflexive) "Structure" method, and the Category knowing that it's an "Element" method, and that its "impl" is found by looking the appropriate method up in the "Element's" methods.
A particularly significant kind of prop that can go on the proplist of a Domain or a Category is a default Element display Environment (which of course can contain (display) rules or procs), or other display-related info (e.g. binding of display-related parameters). subDomains or subCategories can then access this info (by traversing the global Domain and Category lattices, and knowing how to extract it) for determination of, or addition to, the "environment" in which they want their Elements displayed. Thus the display environment for Elements of subDomains or subCategories can be conceptualized as a delta or specialization of that for Elements of the superDomain, Category, or superCategory.