using STEERING in compiled function breaks things

[pellinor0]

A minimal example with two files, using KOS v0.18.2:
tmp.ks:

run once libtmp.
lock Steering to Up.

libtmp.ks:
function test { lock Steering to Up. }

Now I type in the terminal

switch to 0.
run tmp. // => runs fine
compile libtmp.
run tmp. // => Error

ProgramBuilder.ReplaceLabels: cannot add label steering'0-default, 
label already exists. Opcode: push $steering.
At tmp on archive, line 2.

It looks like mentioning 'Steering' in the function definition causes bad things, but only if the function is pre-compiled.

[hvacengi]

This is a known issue with all locks. Due to how locks are compiled differently from variables, there is a small amount of run time information needed to properly handle the default values. Please see the following two issues for more information: #691 and #1253.

Currently, the only work around is to not use locks from within a compiled script. If you are building libraries, I would recommend that you split the lock-dependent code into a separate file from anything that might not need a lock.

It's on our road map to fix, but it's more complicated than my description makes it sound and we have not yet found a good way to implement the fix.

I'm going to close this as a duplicate, but please keep watching the other two issues referenced above to see when we have a solution enacted.