Apparently it's in_interval

I took the freedom of re-naming this issue since this behaviour is intentional and has been extensively discussed. In a nutshell, in Julia the function in pertains to containers (which Interval is not); we cannot remove it completely (throw an error) for otherwise some generic functions fail, we cannot overload it with our own definition since this leads to silent errors in generic code.

We should highlight this in the docs, and maybe just add a docstring for in?

I feel that we may have gone a long way since those discussions, and I am wondering if we shouldn't use the same trick for in that we use for ==, namely

3.2 in interval(3.2)  # True, because the interval is a singleton and `3.2 in 3.2` is true

3.2 in interval(7.9, 12.1)  # False, because for every x in the interval `3.2 in x` is  false

3.2 in interval(0.3, 7.1)  # Error, because no conclusion can be drawn

In fact, for numbers, == and in are equivalent, and we don't have that anymore in the package.

That does seem fair. In fact I believe that's what is implemented in the PR #698. Only functions like intersect, union, setdiff, isempty, are entirely prohibited because their behaviour is ambiguous (behaviour for Number vs Interval).

In today's call we decide to be strict and consider by default that intervals are numbers but never sets with builtin julia function. In particular, this means in should be disabled as ambiguous.

Also, the documentation should contain a section on our general philosophy about it, so that we can refer to it in future discussion.