optionKeyDown message broken

[Paul Dupuis]

I am finding problems with the optionKeyDown handler on both Windows 
(where it's the ALT key) and macOS (OPTION key). This is in Livecode 
9.6.7 STABLE under macOS Mojave and Windows 10

In a new stack, place the following in the card script:

on optionKeyDown pKeyName
   if platform() = "MacOS" then
     put numToChar(charToNum(pKeyName)-128) into tKey1 -- original 
sample from Dictionary
     put numToCodePoint(codepointToNum(pKeyName)-128) into tKey2 -- 
trying using non-deprecated functions
     answer pKeyName,tKey1,tKey2
   else -- windows
     answer pKeyName
   end if
end optionKeyDown

On macOS, the LC 9.6.7 Dictionary shows the need to strip the "high" bit 
off the character to get the letter of the key pressed, for example, 
OPTION-F produces ƒ
The above script on macOS produces for OPTION-F the following ƒ, D, Ë
Where as what you want for either tKey1 or tKey2 to be "F" the key 
pressed with OPTION-F

I think this is a case where the Dictionary entry for optionKeyDown (for 
macOS) needs to be updated with a formula that works since LC was 
updated to Unicode with version 7 "High" ASCII macOS characters are now 
UNicode and not the same character codes.

But Wait. Windows is even worse

This code on Windows does not produce a letter of any sort. It produces  
As soon as you press the ALT key, before you can even press ALT-F, this 
script displays 65513 in the answer dialog. This, I believe is the RAW 
key code for the ALT key!

In other words, the optionKeyDown message is not sending the key pressed 
as a letter/character as the dictionary says and the parameter passed to 
the optionKeyDown message is the code for the ALT key itself (which 
makes no sense).

Could enough folks on this list conform both the macOS and Windows 
errors, so I can log a bug with LiveCode? I am not looking for 
work-around (I can do that if I have to), just for confirmation that 
these are bugs.

The macOS can be resolved by a better method for mapping macOS 
"high-ASCII" characters, now mapped to Unicode in LC, back to the ASCII 
key characters pressed.

The Windows may not have a work-around as, according to the dictionary, 
keyDown/keyUp messages are not passed in Control or Alt keys are down, 
the commandKeyDown, optionKetDown messages are sent instead, so you can 
using a keyDown handler and check for the altKey() = "down" condition. 
Perhaps rawKeyDown...