Hi Jendrik, I can confirm the bug, both for the original revision you're referencing here and with the suggested fix (which looks good to me).
As to why this happens, I have a hypothesis. Our g values and real_g values are not actually correct in general.
Let's ignore the g/real_g distinction for a second and start with something simpler, a standard GBFS (lazy or eager) with no bound and no cost transformations and hence real_g not coming into play. When we find a new path to a node that is better than previous ones and reopening is enabled, we update the g value of this node based on its parent and the action cost. But that means that the g values of all descendants of this node are now wrong, and there is in general no guarantee that they will be reexpanded and update before we terminate. So the g values are in general not internally consistent: for example, we can have a node with a g value of 10 and a parent connected by a cost1 action with a g value of 8.
As such, this is not necessarily a huge problem for pruning and eventual optimality. It cannot cause the kind of problem you're seeing here. In particular, we can only overestimate g due to such errors. (But this already shows that our pruning is a bit shaky.)
Now, with cost transformations we can also get an error in the opposite direction because our reopening and reconnecting of parents is tied to the *original* g values.
Let's say we have a node with state s, g = 10 and real_g = 5. Later, we find a new path to s with g = 8 and real_g = 7. We will update the parent (because we reopen based on g), now switching to the more expensive path. We also update the real_g value to reflect this, but our update also affects the real path costs of the descendants of this node, and *their* real_g values are not updated and are now too optimistic. So I assume in the example we see here, real_g never reaches 43 but the actual real path cost does.
Does this hypothesis make sense to you? Then the next step would be to test it, and then to think what we can do about it.
