Echoing this post... to make clear the implications of "tip-binding" under evaluation...
...in this model, the BLOCK! stored in the CODE variable is what has its tip bound (stored in the block specifier), not the BLOCK! literal that was evaluated to make it (that block's specifier is presumably null):
e.g.:
>> stuff: [
keep: does [print "Outer KEEP"]
code: [keep <example>]
collect code
]
>> do stuff
== [<example>]
>> fifth stuff
== [keep <example>]
>> do fifth stuff
** Error: KEEP is unbound
>> do code
Outer KEEP
== <example>
Here the tip binding of the block stored in STUFF would be to the console's context, received when the evaluator processed the block, which inherits from LIB.
The permissive allowance of KEEP and CODE to be assigned via SET-WORD! to that global context here vs. generate an error would mirror today's behavior... basically saying that unbounds default to trying to pop out of the lowest-level context in the "chain" (not counting LIB). Though I've suggested that might need an analogue to LET that I've called EMERGE when in "strict mode", and that strict mode is probably a better default.