INP and INKEY$ stay the same except that they won't return the scancodes of new keys, like the Windows key. The idea behind this is for QB64 programs to work identically on any computer, so the scancodes returned will match a standard 101-key layout keyboard and not the actual physical keyboard which may be quite different.
The real winners of the input upgrade are our international users, who will be able to enter specific characters from the extended CP437 range using their keyboard without you having to modify your programs for them. Also, with UNICODE input, IME support and the UTF32 font override option all QB64 users can make multilingual QB64 programs if they choose.
It also means my response to "Blah in QB64 related to keyboard input doesn't work properly" will no longer be "I'll address this after I revise QB64's input system", because now I have revised QB64's input system.
I think everybody left because they think that DEF Fn is next
When you set a goal like 100% QBASIC compatibility, you don't say "but". I read the comments about DEF FN and I agree with the concerns raised. I've been programming in QBASIC for many years and the number of times I've accidentally named a variable 'fn....' was only once or twice, to which QBASIC soon informed me something was amiss. Supporting DEF FN is far more important in the greater scheme of things than the rare annoyance it may cause us if it was implemented. However, it isn't much of a priority.
