> I imagined if it might read any fallback file like
> /etc/inputrc, e.g., $INSTDIR/etc/inputrc or something (assume
> there is readline.dll underneath $INSTDIR/bin), without
> particular environment variables.
> Or, setting HOME as $HOMEDRIVE/$HOMEPATH or $USERPROFILE at
> initialization of ruby, like as 1.9 does.

Even this would not help. The conflict is basically this:

Ruby uses (probably for irb, and for those Ruby functions
which are "readline" aware) READLINE.DLL. This DLL *does*
have, to the best of my knowledge, a fallback mechanism
about where to look for a definition file in case INPUTRC
is not set, or simply use the defaults if none is set.

But imagine for one moment that INPUTRC is not set (and
the default inputrc file does not exist) and hence READLINE.DLL
uses its default settings; further assume that we are running
on a PC with European keyboard, and the user starts (in a 
Windows Command Shell) irb. The user would find now that he
is unable to enter certain characters, such as brackets,
curly braces or the '@' character. This would render irb
pretty useless for users in, say, Germany (and probably
also for other European countries using a similar approach
to generate these keys on their keyboard).

Therefore, the Ruby installer (probably by looking at the
Windows registry - but this is just my guess - finds out that
the computer is using a (say:) German keyboard, creates a
file named inputrc-euro somewhere below its $HOME which fixes
the keyboard behaviour for European keyboards, and
changes, respectively creates, a Windows environment variable
named INPUTRC.  

This is all fine and dandy, unless we have on a computer a
different application, such as Cygwin, which also depends on 
the INPUTRC variable, which would mean that both (Cygwin and
Windows-Ruby) need to do their READLINE handling in different
ways (Cygwin does not suffer from the keyboard problem, because
they seem to have their own Readline; but instead, Cygwin users
are used to put a lot of other useful stuff into their INPUTRC).

As a consequence, no application should ever create (or modify)
the Windows settings for INPUTRC. Instead, the conflict should
be solved in that an application which *needs* particular
inputrc settings for Windows, should either always set INPUTRC 
locally, or hand over the responsibility to the user. As far
I can tell, this should not be too difficult to do (and of
course I will be happy contribute here by discussing possible 
solutions to this problem with the implementor of the setup program).

Best regards,

Ronald