> Doesn't that readline.dll have the default value of INPUTRC?

Yes, but this is not the point. I don't claim that Ruby should not
use readline.dll at all (it is very useful indeed and I have described
an alternative solution, which would allow Ruby to use readline.dll
without
changing the system-wide settings). The problem is
that the Windows installer for Ruby *silently* changes the system-wide
value of this environment variable (or creates it, if it does not
exist). In both cases, this can interfer badly with other software
installed. 

I mentioned the problem with Cygwin because I happened to have stumbled
over it, and also because it is not unlikely that other people will face
the problem too (if you, for example, develop Ruby programs intended
to run on various platforms, it is not unlikely that you have the Cygwin
version of Ruby and the Windows version installed at the same system).

I could imagine, however, conflicts with other packages who happen
to use readline.dll too. In general, I think that an application should
never change an environment variable which it does not "own"
exclusively,
or at least give the user a chance to interfere. Readline.dll is a
generally
used library. Now suppose I have already installed several programs
which
use readline.dll, and I have set my INPUTRC environment variable to
point
to a file where I define my readline bindings. Then I install Ruby for
Windows, and suddenly, my other programs don't work anymore, because
INPUTRC has been changed. This is certainly not what the user would like
to
have.

These principles do apply to *all* "commonly used" environment
variables,
not just INPUTRC. For example, a (well-behaved) Windows program would
certainly
not secretly replace the value of PATH, PATHEXT or CLASSPATH (though it
may 
*add* its own entries to them, leaving the others intact), nor would it 
set TEMP or TMP to different locations - at least not without asking the
user for permission.

Kind regards,


Ronald