This is currently by design. The top end is currently exclusive, so it's essentially doing the comparison lower <= n < upper. This is because otherwise adjacent ranges become overlapping. For example suppose you have:
Is between 0 and 90 degrees: do A
Is between 90 and 180 degrees: do B
It seems reasonable to expect that it would only ever do A or B. However if we make the range inclusive, it becomes possible for both conditions to be true at the same time, when at exactly 90 degrees. This may be a bit of a surprise, and is also tricky to work around: you have to make the second condition "is between 90 + tiny amount and 180 degrees". Then there's a possible secondary bug where if the object is pointing just in between 90 and 90 + tiny amount (which is easily possible with floating point precision, e.g. doing a calculation that results in 90.0000000000000001 degrees), then neither condition is true, which is even more confusing.
So I don't think this should be changed. It would also be a non-backwards-compatible change, which could break projects. Perhaps we could add an extra parameter to make it an inclusive check.