> With what?

I agree with @tsauerwein that this can be addressed with a separate pull request.

> What I'm saying is that an interaction that modifies the view state should set the interacting hint. This doesn't require sharing this.handled_.

I think I understand what you are saying, and I agree with you, but I also think that this code/logic is sensitive and easy to break.

Some observations:

* Currently we make sure we don't set the interacting hint again if we already set it. The `this.handled_` variable is used for that. So if a pointerdown was handled already, then we will not set the interaction hint again if a second pointer is added to the screen.

* In the case of the DragPan interaction we set the interacting hint even though handlePointerDown did not change the view state. We need to set the interacting it because handlePointerDown requested a render frame.

> If I wanted to create an interaction that extended ol.interaction.Pointer but didn't necessarily modify the view state (e.g. maybe it just draws a box), the interacting hint would be incorrectly set.

True. We do set the interacting hint when drawing zoom boxes today, although it may not be necessary.

So, I agree with you that the specific pointer interactions should be responsible for setting/unsetting the interacting hint, but I think making the required changes is not trivial. Hence my recommendation to address this in the separate pull request. @tsauerwein "just" ported the interactions and kept the current "view hints" logic.