Hi there, As promised, some proposals for the symbol table. No code yet, because careful thinking is needed first, to avoid unexplainable side-effects. Let me propose two rather straightforward new primitives first (please imagine the \ptex prefix yourself): \ifprimitive <csname> True if the <csname> has the same meaning as it would in initex, (but gives an error if <csname> is currently undefined). \executeprimitive <csname> Executes the primitive that would be known as <csname> in initex, even if the <csname> is currently undefined or defined to mean something else. Raises an error if there is no matching internal command (of course). These are quite straightforward, and I do not assume this needs much discussion. But the next ones are related to "if feature ...", and those are bit harder to define. I propose to make it possible to 'predefine' primitives in the executable. All program code is completely ready, except that the hash table entry is never created, making it impossible to use that primitive in initex without extra work. \ifinternal <csname> True if there is code in the pdtex executable to implement the internal command <csname>, regardless of whether or not it is currently reachable from macros. \executeinternal <csname> Executes the internal that is registered as <csname>, even if that internal is currently obscured (disable) or the <csname> is defined to mean something else. Raises an error if there is no matching internal command. \exposeinternal <csname> This does the final step of the primitive() function: it creates a hash entry for <csname> that maps it to its primitive meaning. An error is raised if the <csname> is currently defined. (perhaps this primitive should accept the \global prefix?) \obscureinternal <csname> The inverse of \exposeinternal, this 'undefines' the primitive related to <csname>. If <csname> is currently a macro, nothing needs to be done. Control sequences that are \let to the meaning of this csname are left as is. (perhaps this primitive should accept the \global prefix?) I chose \expose... and \obscure... instead of \disable... \enable because this is closer to the truth: in this proposal it is not possible to unconditionally disable a primitive (because that would require much more work than this). Side note: The pascal implementation can be rather straightforward: a pair of shadow_hash and shadow_eqtb has to be created that contains only the equivalents of the internal control sequences, nothing else. WDYT? Greetings, Taco