Multiple cases of ISTATS weirdness

I'm having some problem with ISTATS on a LTM 8900 running version 11.2.0. Perhaps anyone here could help me out shed a light on what is the reason for these cases of weird behaviour.

1) The counter name apparently requires to have three spaces in it. For example, this works:

ISTATS::incr "foo bar baz zoo" 1

However, this doesn't:

ISTATS::incr "foo bar baz" 1

It fails with the following error message:

01220001:3: TCL error:
/Common/istats_debugging  -  Error: Fact0: requested Id0
(type=HEADER) as type FACT (line 1)     invoked from within
"ISTATS::incr "foo bar baz" 1"     ("/incr" arm line 2)     invoked from
within "switch [HTTP::uri] {     "/get" {       HTTP::respond 200
content " counter is now: [ISTATS::get "foo bar baz zoo"] "     }
"/incr" {       ISTATS..."

As far as I can tell, this restriction isn't documented at https://devcentral.f5.com/wiki/iRules.iStats.ashx. What is the reason for this?

2) The third word in the counter name appears to be ignored. In other words, if I have done:

ISTATS::incr "foo bar baz zoo" 1

...and later check the value of another counter that share the first two and the last word in the key, for example:

ISTATS::get "foo bar HAHA zoo"

..it will return 1, even though this particular counter was never initialised.

3) ISTATS::set appears to be interpreted as ISTATS::incr. For example, after doing:

ISTATS::incr "foo bar baz zoo" 100
ISTATS::set "foo bar baz zoo" 50

When reading this counter:

ISTATS::get "foo bar baz zoo"

I get the value 150. I would have expected 50 instead.

This makes it impossible to reset the counters, as using ISTATS::set with the value 0 does nothing (probably "adds" 0 to the existing value).

4) There is a noticable delay in updating the counters. For example, if i have an iRule that says:

ISTATS::incr "foo bar baz zoo" 1      
HTTP::respond 200 content "counter increased by 1, current value: [ISTATS::get "foo bar baz zoo"]"

The actual output of this iRule will be:

counter increased by 1, current value: 0

...which ought to have been impossible the way I see it.

5) There is a certain "wobblyness" in updating the counters too. In the example below, the /incr URI will increment and print the value, while the /get URI will only print the current value of the counter (I will attach the iRule).

$ wget -qO- http://192.168.0.254/get
counter is now: 11
$ wget -qO- http://192.168.0.254/incr
counter increased by 1, current value: 11
$ while sleep 1; do wget -qO- http://192.168.0.254/get; done  poll the counter every second
counter is now: 11
counter is now: 11
counter is now: 12
counter is now: 12
counter is now: 11
counter is now: 11
counter is now: 12
counter is now: 11
counter is now: 12
counter is now: 11
counter is now: 11
counter is now: 12
counter is now: 11
counter is now: 12
counter is now: 11
counter is now: 11
counter is now: 11
counter is now: 12
counter is now: 11
counter is now: 11
counter is now: 11
counter is now: 11
counter is now: 11
counter is now: 11
counter is now: 12
counter is now: 12
counter is now: 12
counter is now: 11
counter is now: 12
counter is now: 12
counter is now: 11
counter is now: 12
[permanently 12 from now on]

This means that from the stats gathering tool, it may appear as if the counter is going backwards, which is usually considered a counter wrapping, either leading to lost data points or huge spikes in the generated graphs.