We can't get rid of plurality of meaning because syntax isn't semantics. The same syntax can be assigned completely different semantics.

In Lisps, we program syntax with different semantics regularly, so the plurality is part of the daily existence. (defclass a (b c)) and (list a (b c)) have the same shape, but are completely different things.

10 is a piece of syntax, but how do we assign its semantics when it is an argument to a parameter that expects a sequence? That is up in the air the same way. Is it an error, like in most Lisp-like languages? does it count up to 10 from 1? Below 10 from zero? From 10 ad infinitum?)

The choice becomes a paradigm in the language that everyone has to understand.

What is undesirable is inconsistencies. If certain functions counted up to the number, but others from the number, arbitrarily, that would be objectively worse than consistently doing one or the other.

It would not be often useful to have it count up from 1 or zero up to or below the value; I would not have designed it that way. In many situations you don't know the upper limit of what is enumerated; it comes implicitly from the lengths of other sequences or in other ways.

It's also less inefficient, because the value has to be converted to an iterator object that knows about the range, and keeps track of the state.

In TXR Lisp, certain objects are self-iterable, like characters, numbers and good old conses.

  1> (iter-begin "abc")
  #<seq-iter: a031a10>
  2> (iter-begin 3)
  3
  3> (iter-begin '(a b c))  
  (a b c)

To iterate a string, we need to obtain a seq-iter object, but for 3 and (a b c), we do not. With these objects, we have all the state we need in order to iterate.

  4> (iter-more 3)
  t
  5> (iter-item 3)
  3
  6> (iter-step 3)
  4
  7> (iter-more '(a b c))
  t
  8> (iter-item '(a b c))
  a
  9> (iter-step '(a b c))
  (b c)
  10> (iter-more *1)
  t
  11> (iter-item *1)
  #\a
  12> (iter-step *1)
  #<seq-iter: a031a10>
  13> (iter-item *1)
  #\b

iter-step may or may not destructively update its argument, so you always have to capture the return value and forget about the original.

You can see how for a list, iter-more is equivalent to (not (null ...)), iter-item is just car, and iter-step is just cdr.

There is also lazy processing in TXR Lisp. E.g. lazy mapcar which is mapcar*. The following will only read the first few lines of the syslog, returning instantly:

  14> (take 3 [mapcar* cons 1 (file-get-lines "/var/log/syslog")])
  ((1 . "Jul 23 00:09:54 sun-go systemd[1]: openvpn@client.service: Service hold-off time over, scheduling restart.")
   (2 . "Jul 23 00:09:54 sun-go systemd[1]: openvpn@client.service: Scheduled restart job, restart counter is at 1044619.")
   (3 . "Jul 23 00:09:54 sun-go systemd[1]: Stopped OpenVPN connection to client."))

Counting from 0 up to a value is the standard for loop, or numbering things (possibly with using the value with an offset).

But like I said, I'm not so sure there is a right way to interpret it any more.