Trying to compile type::var caused an infinite recursion.
BYOND Version:515
Operating System:Windows 10 Pro 64-bit
Web Browser:Firefox 117.0
Applies to:Dream Maker
Status: Resolved (515.1621)

This issue has been resolved.
Descriptive Problem Summary:
Attempting to compile code using the new type lookup pattern (in typedef) looking up the var we are setting causes a hard crash

Numbered Steps to Reproduce Problem:
Literally just what I said above

Code Snippet (if applicable) to Reproduce Problem:
var/stuff = ""
stuff = type::stuff + "test"

Expected Results:
stuff to be redefined in terms of its old value + the new

Actual Results:
Dreammaker hard crashes

Does the problem occur:
Every time? Or how often? Ever time
In other games? N/A
In other user accounts? N/A
On other computers? N/A

When does the problem NOT occur?
When looking up a var other then what we are setting
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit to download old versions for testing.)

This is a major usecase for derivative ss13 codebases that try to avoid modifying the source code files of the codebase they're based on. So they redefine procs and vars in seperate files, keeping them compatible with future updates to the upstream project.
Lummox JR resolved issue with message:
Trying to compile type::var caused an infinite recursion.
In response to Ninjanomnom
I don't think it's appropriate for type::var to work this way, so probably a new keyword is needed for 516 that explicitly refers to a previous definition rather than type or parent_type (although it'd obviously be parent_type if there is no other definition on the current type to override). I'm very open to suggestions for such a keyword.
If there was any way of explicitly referring to a previous same type override already in existence I could see using a similar pattern, but the closest thing I can think of is ..(), which doesn't give us much of an example to reuse here.

A new keyword here in place of the type reference seems odd here, perhaps a generic way of referring to the var when using :: that tells the compiler that you want the version as it currently is at that point in time? Like if we went with prefixing .. to the var to mean that we want the value currently defined without waiting for all the overrides to finish getting processed.

The pattern here is how many derivative codebases would want to use this so as to avoid touching any upstream code directly and avoid conflicts:
// Main codebase code
#define CAN_DO_COOL_THING (1<<0)
#define CAN_DO_OTHER_COOL_THING (1<<1)

// Bitfield of cool stuff this thing can do
var/capabilities = CAN_DO_COOL_THING

// Derivative codebase code in a different file
capabilities = type::..capabilities | CAN_DO_OTHER_COOL_THING

// A derivative codebase of the derivative codebase (yes this is a real thing)
capabilities = type::..capabilities & ~CAN_DO_COOL_THING