[vsaraikin]

Set one ulimit key in the base file and a different one in the override, and the base key disappears:

# base                # override
ulimits:              ulimits:
  locks:                locks:
    soft: 20000           hard: 65535
    hard: 40000

# got                 # want
locks:                locks:
  hard: 65535           soft: 20000
                        hard: 65535

mergeUlimit receives the base value and the override value, but it reads both mappings out of the override:

func mergeUlimit(_ any, o any, p tree.Path) (any, error) {
	over, ismapping := o.(map[string]any)
	if base, ok := o.(map[string]any); ok && ismapping {
		return mergeMappings(base, over, p)

So it merges the override with itself. The base argument is named _ and never read. Every other function in mergeSpecials takes its first argument as the base, this one is the exception.

Test_mergeYamlUlimits already covered the case, but its expectation encoded the old behaviour, so it is updated to expect the base soft to survive. Reverting merge.go alone makes it fail. Full suite is green

[ndeloof]

Verified locally: the updated test fails with the previous merge.go (the old expectation encoded the buggy output) and the override+loader suites are green with the fix. Merge semantics for the scalar/mapping mismatch cases are unchanged. I'll follow up with an additional test covering short/long syntax combinations.