There’s a subtle bug hiding in the German Map Style Lua script, which your uMap instance uses as its default tilelayer.
The script walks through every tag on an OSM object and rewrites certain tag values using a generated localized name string (gen_110n_name). If an object has tags like ref, source, name, and highway, the script touches each of them in sequence, and whenever a tag requires localization, the script updates the Lua table that stores all tags.
That’s where the problem starts.
OSM tags inside the script live in a Lua table indexed by strings, so ordering depends on the table’s internal hash layout rather than numeric keys. Lua’s hash table can reshuffle entries whenever it grows during a hash-slot-shortage situation. When the script updates a tag mid-iteration, the underlying table may rehash itself, altering the traversal order.
Imagine the table initially hashes as: ref → source → name → highway. The script processes ref, then source, then reaches name. Updating the name forces the table to grow (My guess is that, in this name-localization context, the table grows when a new name:country_code tag is added), and if (by some bad luck) there are no free hash slots left, Lua rehashes the keys into a new order, for example: source → highway → name → ref. The loop then continues from where it left off (name → ref), landing on ref again while skipping highway entirely. Result: the ref tag is processed twice and highway vanishes from the final render.
Whether this happens depends on hash capacity. Lua sizes the hash portion in powers of two (1, 2, 4, 8, 16, 32, …). If an object has five tags, Lua picks the next power of two (8) leaving three empty slots. Objects with long tag lists usually get large tables with plenty of spare slots, so they rarely trigger a rehash. Small objects get tiny tables with only a couple of free slots, making them much more likely to hit this edge case.
TLDR : German Map Style’s Lua script has a bug in how it handles tag iteration on mutable Lua tables. Switching your uMap tilelayer to any other style probably avoids the issue entirely.