Selective reification exploits the well-formedness of triple scripts' file format to treat the text like code-as-data-as-code and allows specific classes (or functions, etc.) to be extracted for use by the program reading it.
This is made possible because the concatenated t-block format, although not a general purpose container format, is generic enough to encode and link additional payloads, and simple enough to make it trivial to extract the desired blocks (or entire subtrees of some given block(s)), and the restrictions of the triple script dialect guarantee that the definitions in those blocks are (for the most part) free of side effects.
(NB: When we speak of guarantees, this should not be taken to include an general safety guarantee against untrusted inputs. Inaft—see below—is able to use fairly simple processing—that might superficially seem "careless"—because this is only because it's operating on its own code, which is a trusted input.)
Inaft (the very first triple script program) uses selective reification to extract helper class definitions from its own bundle and define them in child execution contexts that are otherwise isolated from Inaft's own execution context.
trplkt, with its "decompile" command doing work that somewhat resembles the extraction step, is not said to use selective reification. trplkt decompile is just doing a straightforward decomposition—the resulting pieces are never reified (in the execution sense, although they do get written to disk).
Triple scripts and the triplescripts.org Build Manifesto already being inspired by Smalltalk, we can look to Smalltalk for further inspiration.
Advanced forms of selective reification present a way to treat the entire program as an object and send messages to it (in the sense of Smalltalk message passing). At this point, there is no (known?) use of this kind of advanced selective reification, but inspiration and opportunity exists. See 280 North's old Atlas Plugin Tutorial covering an Interface Builder-like tool with inspectors. When sepsis-inspector was in active development, the viewer contract design included static definition (in JSON) of metadata that ultimately needed to yield dynamic behavior. To allow the inspector internals to filter for applicable viewers, viewers have to register their metadata file and use a complicated schema to advertise which kinds of objects the viewer accepts. This was straddling the wrong place in the static/dynamic divide, and could have been made easier if viewers were implemented as concatenated t-block bundles and selective reification were used instead.