> I don't really see these as being inconsistent; /some/path/some-basename is a
> path name, and the named file either exists or it doesn't.  

---

It either exists in "some case" or not (on a case sensitive file system).

> The tests implemented by find (such as -iname) are essentially a query
> language allowing the user to specify which files they would like to see in
> the results.

---

Right -- and the initial directory list is a list of starting points
or subtrees where you would like the query to return results from.  I.e.
the starting points are part of the query.  With different starting
points, it is a query that returns a different result -- just like DNS.
If I query for "Eng.machine_a", I might get an answer if my DNS server
defaults to "ibm.com", vs. on the outside, it would likely return an
error.
 

> These are, in my conception of things at least, different concepts. 

---
They can be viewed arbitrarily based on any persons definitions.
I don't see that as being of primary importance.


 

> If /foo/ is a case-insensitive file system, then surely "find /foo/BAR" and
> "find /foo/bar" should produce similar results.  Identical in fact, apart from
> the case of "BAR" in the output.   I believe this should already be happening
> (or am I wrong?).

---

I don't know.   I made no mention of a case-insensitive file system.
That would be something outside the realm of find.  I am only talking
about how find processes arguments given to it (on a command line or
in an argv array).

> TL;DR: Start points are treated case-insensitively if they exist on a
> case-insensitive file system, and case-sentively if they exist on a
> case-sensitive file system.

---
I'm referring to arguments given to 'find' -- not features of a file
system or OS that are outside of find.  The "iname" option functions
independently of the the OS and file system.  That is the only
functionality that I am saying is missing in the path processing on the
command line.  Switches on find's command lines can say to process paths
or regex's in a case insensitive manner, but nothing allows for ignoring
the case of the "base" or "starting point[s]" of the query. 

To use your filesystem argument as an example -- if a filesystem has
stored randomly "cased" filenames, because some people wanted "Home" and
"Doc" instead of "home" and "doc", find has no way of specifying that it
should ignore the starting path's case.  If "ignoring case" of items to
search for was considered necessary enough to provide case-ignoring
options for path and regex (where it isn't really necessary anyway), it
seem that being able to ignore the case of the starting path would be
equally important.

TL;DR: Filesystem features are not part of a query that one can control.
It doesn't seem logical to divert a discussion of how find processes its
command line arguments to things outside the domain and control of find.

The point is how to tell find to process paths case insensitively and
how to include or access such functionality for the query start point.

A starting path is one given on the command line telling find where to start the search, i.e: the 'path' in:
     
  find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression]


Ex:
/tmp$ touch a
/tmp$ find A
find: `A': No such file or directory
/tmp$ find -i A
find: unknown predicate `-i'

Note that while a -i form ignores case for all other path options, it doesn't work for the path telling find where to start the search.

Also, please note: ignoring case of paths was considered a necessary feature of find, but it doesn't work for starting paths.   I would (and did) consider this to be a bug (even though it may have been forgotten during the design phase).  I wouldn't consider consistent treatment for paths to be something that fell into the category of a 'wish'.  However, given my experience with some paid products, recently, even being able to 'install' software is sometimes not something that some companies consider to be a supported feature.  :-/  (sigh)...

While find has options to ignore case on the linkname, name and regex options, there is nothing that will allow it to ignore case for the starting path options.

I don't understand why case ignore was provided on 3 of the name match options (-name, -regex, -lname), but left off the 4th (starting name).  Seems like a gaping design hole to do it in in 75% of the name match options, but leave it off the 4th.

The need to fix inconsistent user interface options, IMO, should have been a high-priority item as soon as it was decided to implement that feature for the other options. 

However, given the rise in the use of linux servers for windows, it can only be that its priority would be even higher now.