When I'm in a micropause, the timer doesn't stop, even if I move the mouse or 
toch keys. Therefore, my micropause then ends without me 'really' being forced 
to rest.

I don't know if this is a feature, if so, I don't see the use of that feature :)

WR has 3 options wrt activity during an insisted break:

1) ignore activity
2) stop the timer (but don't reset the timer to 0:00s)
3) stop and reset the timer.

Option 1 is WR 0.1.0 behaviour. Now, option 2 is used. 
Unless someone starts shouting, this will not become configureable.

Shout!

If you take a look at taking a natural break: If you become active during a 
natural break, the timer is stopped and reset.

I think you want the same behaviour on insisted breaks.

Anti-shout.

It really doesn't make sense to make this configurable. I think we should force
KJ to a "cool-down period" of 3 months. If, after that time he says "I  want"
instead of "I think you want", then perhaps we can take this under consideration.

Sorry for ranting. :)
We have two choices here:
1) do as it is now, meaning stop the timer.
2) stop and reset

IMNSHO, 2) is considerably more irritating to users. Suppose you have a break of
10mins, and you only have 1 min to go. When you accidentally become active, the
break restarts and you'll need another 10 mins.

I don't care very much about this specific functionality. I do care about 
consistency. The current situation is inconsistent.

I consulted wp. Apparently, in restbreaks the timer is not reset if you become 
active. It isn't even stopped. 

Micropauses are an entirely different story. Not only is the timer reset, but 
the "idle" value (or at least wp's counterpart) is increased from 2s to 20s, 
forcing me to effectively break 50 seconds.

Apparently, wp is inconsistent as well, even more so than wr.

As for accidentally becoming active: That should be covered by the noise 
detection algorithm.

Overall, I guess I still am in favour of resetting the timer. For consistencies 
sake. But it's only a small favour :-)

You should not aim for consistency, but rather for usefulness. Consitency is
only secondary. Furthermore, we do not live in a binary world, so consistency is
always hard to maintain.

> As for accidentally becoming active: That should be covered by the noise 
> detection algorithm.

With your monitoring defaults, chances are high it won't.