about the first one here:

if (true) &0: (t | *f64) else null;

if null wouldn't directly be assignable to t without a cast, this example could just error out with one of your solutions? it would at least fix the issue in one of your solutions of having to treat aliases as pointers, because you'd have to explicitly cast to the alias?

i think that, at least in your first case, the problem is more a problem in the side of type alias assignability rules, isn't it? i think the current rules around that are Not Nice and IMO it'd be a better idea if we'd disallow assigning the underlying type of an alias directly without a cast. that'd solve some of the issues here, and a ton of other, very weird, issues.

the other one:

let z: nullable *int = if (true) x else x;

oof. i don't know about that one, it's weird, but maby it should stay this way, yeah. it's probably okay.

i think _ = <expr> is kinda weird and should probably just be let _ = <expr>? anyways, yeah, it'd be nice if we could allow both, also for consistency.

btw, this should probably be an RFC?

+1 for me too because this would be a nice thing to have in for-each loops where you just care about the length of an array and not of the elements that it has itself. seen that a couple of times in the stdlib already. so i.e.

for (let _ .. [1, 2, 3]) {
        do_thing();
};