Attached is a changeset making the change to how N is used. It also removes what looks like a duplicate test on some local variable. I then saw a FIXME in there about cruft related to caseinsensitive greaterthan and lessthan test, so I looked at the background of that and decided that can go. The code are fairly short routines that can be recoded without too much thought, plus JWE introduced the use of C++ classes five to eight years ago such that the lexicographical comparisons are done deep within Array or its relatives. So either that lexicographic test would have to be done there, or a more local solution would be to first convert 'table' and 'y' to upper or lowercase before applying the lookup methods.
However, as regards to the actual use of caseinsensitive code in the app, I found the following references to the use of an 'i' option around 2010, and I conclude this 'i' option isn't coming back:
http://lists.gnu.org/archive/cgibin/namazu.cgi?query=lookup+case+insensitive&submit=Search%21&idxname=octavemaintainers&max=20&result=normal&sort=score
http://lists.gnu.org/archive/html/octavemaintainers/201010/msg00134.html
http://hg.savannah.gnu.org/hgweb/octave/rev/30f54b3b9953
http://hg.savannah.gnu.org/hgweb/octave/rev/566249cf97fb
http://hg.savannah.gnu.org/hgweb/octave/rev/48cb431db87b
The main issue was that applying toupper or tolower inherently introduces a scrambling of the 'table' strings which puts it in the "undefined behavior" category. So really, if a user is interested in caseinsensitive analysis s/he would be best using toupper and tolower and sorting prior to the lookup() routine.
(file #42862)

The answer is:
< M A T L A B (R) >
Copyright 19842017 The MathWorks, Inc.
R2017b (9.3.0.713579) 64bit (glnxa64)
September 14, 2017
To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit http://www.mathworks.com.
>> linspace (0,0,5)
ans =
0 0 0 0 0

Just a couple things related to these changesets.
First, in the "Doesanyonereallycare?" category, what should be the result for the following? It doesn't look evenly spaced (chuckle):
More seriously, the documentation for lookup() indicates
It's a couple paragraphs later where 'n' is defined, as
Perhaps the definition should be brought to just after the first use of 'n'. Or, instead of 'n' in the first instance, it could be "then 'idx(i)' is 'size(table)'" since the expression table(end) was used.
To be technically clear, the following option is "extended to minus infinity for table increasing and infinity for table decreasing" rather than just "extended to infinity".
i.e.,
but I guess the current documentation captures the gist of it.
I'm sort of wondering about the usefulness of 'l' and 'r' options, as these two kind of obviate the first and/or last table boundary. Instead of using 'l', one could just add one to the non'l' result:
That is, the thought that comes to mind is that someone is putting a bogus left (right) boundary in his or her table just so s/he can use the 'l' option. And if that person is going to add another boundary at the front of the array, s/he must think about the increasing/decreasing aspect of it. Also, one could do the following:
and achieve a similar result to 'lr'. That is, rather than put in some arbitrary left and right extra boundary and use 'lr', just use inf and inf.

Hi,
in the newest version there is one 'val' left which should be 'y' as well.

help lookup:
There is no definition of variable 'val'.
'val' might be 'y' according to the context.
help logspace:
The behavior of logspace is that
if N==1, it returns 10^B or pi, but not 'B'.
