Yes, I suppose that the NoOp would trigger a new delta2update, since it would push another model through the signal graph. Of course, it's the same model (as you say, you do nothing with it), but I'm not sure we can test for that (in the general case), since we don't know what's in your model, and it might not work with Elm's equality test (which is partial). I suppose that we could ask for a (perhaps optional) equality-testing function in the configuration, and use it if supplied.

Now, your delta2update function is supplied with both the old and new model, so I suppose you could do the testing for equality yourself (if your model is suited to it) and return Nothing if they are the same. It's possible that might help your case.

In any event, if it's happening occasionally, then it sounds like a race condition. There must be two async things happening here, which normally happen in the desired order, but sometimes not. If I recall correctly, History.setHash is implemented inside a setTimeout, so it's async. So, normally you'd expect it to happen after the NoOp is processed. However, sending actions to addresses is also inherently async, so perhaps occasionally the delta2update triggered by the NoOp happens after the History.setHash? It must be something of that kind, at any rate.

Of course, elm-route-hash isn't aware of your explicit use of History.setHash, so it's not straightforward to special-case it.

All that being said, the general philosophy behind elm-route-hash is that ideally you shouldn't go through the hash in order to change your model -- you should just change your model in the ordinary way, and let the hash follow along. (That is, the url handling should sit alongside your normal state transformations, rather than being an essential part of them).

So, ideally the best way to attack your problem would be by figuring out how to deal with this:

However, inside a partial page, it seems not possible to update the model of the root page.

Now this, it seems to me, is an example of the general question of "How does a sub-component trigger a change in a parent's model?" And that, in turn, is a common question of general interest.

In principle, there are only two possible answers:

• the parent passes something in that the child can use to construct an Effect; or
• the child returns something the parent can look at.

Which, generally speaking, means modifying the standard signature of the child's update function to either:

• include an extra parameter (often called "context", being a record of whatever additional things the child needs -- for instance, possibly an Address to send actions to); or
• include an extra thing in the return type (i.e. something in addition to the model and an Effect), which the parent might consult.

I did a little googling around children updating parent's state in Elm, and got this (amongst other things), which suggests one plausible approach:

https://www.reddit.com/r/elm/comments/3plxaw/child_component_changing_state_on_parent/

Of course, I may have misunderstood your needs, but I think figuring out how to get children to update their parent's state might be helpful in your situation.