Bug: inconsistent key name when using &to layer-name in ZMK layout

[floating-cat]

I have a ZMK keymap that in location 1 and 2 below, it uses To-on-Tap, Momentary-on-Hold Layers behavior like this ZMK example here so for location 1 when I am holding the left thumb key, it applies momentary Nav layer, and if I tape it, it enables Nav layout and disables all other layers except the Base one.
Also, in location 3 below, I use &to Base.

The problem is:

1. It shows "toggle layer-name" for location 3 but shows "layer-name" directly for locations 1 2's tap location.
2. It shows "toggle layer-name" instead of "to layer-name" for location 3.

Expected:
It shows "to layer-name" for location 3 and also shows "to layer-name" directly for locations 1 2's tap location.

I tried to use:

  raw_binding_map:
    "SMART_NAV": {s: to, t: Nav, h: Nav}
    "SMART_MOUSE": {s: to, t: Mouse, h: Mouse}
    "&to BASE": {s: to, t: Base}

but due to #113, it short circuits the usual processing when using raw_binding_map so the held property doesn't work causing another issue.

Fixing this name inconsistent or making the processing not short circuits, either way works fine for me.

Thanks!

[caksoylar]

Thanks for the clear issue description. There are a few things here:

1. &to and &tog both getting "toggle" legend (as determined by draw_config.toggle_label setting) is me being lazy and not wanting two separate config values. Subjectively I find calling &to also "toggle" good enough but it's fair if you don't
2. I assume that toggles/stickies are usually used not inside hold-taps, hence I thought adding "toggle/sticky" to the held field and not modifying the tap field with a prefix like you suggested is reasonable
3. Using raw_binding_map preventing held layer inference from working, like you noted at the end

Since 1. and 2. are always going to be subjective decisions, I would like to prioritize fixing 3. Currently I am leaning towards providing a custom_layer_activators config to be used alongside raw_binding_map, as described in #148 (comment). Hopefully it won't take me too long.