A recapitulation for all who just jump in. First, what I think we agree
about:

(1) All existing search syntax must continue to work
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is:
  date1;date2
  date1;
  ;date2
  from date1 to date2
  date1 to date2
  from date1
  to date2
  # (date specs can contain spaces in Roundup; this is important)

--> The semicolon ";" is the "range operator";
    it can be replaced by 'to'

  1, 2, 5    # for integer values and ids
  1 2 5      # for ids

--> the comma ',' separates enumerated single values

As far as possible, all types of data should be handled likewise
in search expressions.

This is not possible to the full extent, since ids can be separated
by spaces, but dates -- which can /contain/ blanks -- can't.

From the user's point of view, ids *are* integers; therefore, they
should be treated identically when it comes to search expressions.

Ranges can be specified as "open" and "closed" intervals, following the
"set builder notation"
<http://en.wikipedia.org/wiki/Interval_(mathematics)#Excluding_the_endpoints>

  [date1;date2)   --> date1 <= x < date2

(this is what date ranges currently work like)

  [a; b]          --> a <= x <= b
  (a; b)          --> a <  x <  b
  (a; b]          --> a <  x <= b

It should be possible to combine range expressions:

  [;v1] or [v2;]
  [;v1], [v2;]

This would allow to seek values x with

  (x <= v1) or (x >= v2)

which can't be achieved with [v1; v2] if v1 > v2.

Ralf calls this a set of ranges.
I call it or-connected ranges.

Furthermore, it should be possible to specify in one expression
/both/ a number of known values /and/ ranges; how this is should look
like, is subject to our discussion.
Ralf calls this number of values "degenerated ranges" (which contain a
single element each only).
I call this enumeration of values a set.

Finally, before I make a point here to give Ralf the oppurtunity to
countersign the text so far:

We agree that it should be possible to specify float values with decimal
commas.  Many Roundup users like in countries live in countries which
use decimal commas, where the decimal point is known to computer geeks
only (Germany, for one).

Of course, this seems to conflict with the comma as an enumeration
indicator. This might can be solved when using a special tokeniser for
float searches (which is a small and perfectly testable piece of code),
which could require the comma /separator/ not to be followed by a digit.  
But the problem could be a non-issue anyway, since float arithmetics is
unprecise, and it might make sense to disallow both enumerations and
closed intervals ("[a;b]" --> a <= x <= b) for floats, since comparison
for equality is unrelyable for them.