I could not reproduce this locally. Expansion numbers are the same up until the
last good output (h = 128), but then I got another good output locally for
h=127, where I got the negative output on the grid.

New best heuristic value for operatorcounting(list(state_equation_constraints,
lmcut_constraints)): 128
[g=180, 138140 evaluated, 21539 expanded, t=4518.19s, 140920 KB]
New best heuristic value for operatorcounting(list(state_equation_constraints,
lmcut_constraints)): 127
[g=181, 290104 evaluated, 46327 expanded, t=8478.8s, 186540 KB]

Running the following configuration on airport/p29 reported a negative heuristic
value after running for 6172.15s.
Since all operator costs are non-negative and operator-counting variables can
only take non-negative values, this should not be possible. The log is attached.

./fast-downward.py --build=debug64
../benchmarks/airport/p29-airport4halfMUC-p8.pddl  --search
"astar(operatorcounting([state_equation_constraints(), lmcut_constraints()]),
pruning=stubborn_sets_simple())"