PlaneShift

could not reproduce, Ubuntu 9.10 US (have you tried a different keyboard?)

LShift=Left Shift key, RShift=Right Shift key, same for other modifiers.

Have tried just German, sorry. [EDIT: There are so many variables involved in keyboard definitions that trying to establish a common baseline is probably futile.]

BTW that non-existent Shift key gets unstuck if I switch to another application and go back. This works regardless of whether I use Alt-Tab (keyboard action) or click on application symbols in the task bar.

Clarification: After LShift-clicking inside the inventory, PS changes to the state "Shift is being pressed". It thinks so even though it is impossible for me to reproduce a "Shift" keypress (as seen in the Shortcut editing windows).
I have verified this by defining shortcuts. With that Shift state active, any shortcuts that I define will have that bogus "Shift" modifier. E.g. defining a shortcut that uses "x" will have PS tell me the shortcut is for "Shift+x". Defining a shortcut that uses Shift-X will make PS think "Shift+LShift+x" (sic!).

Might that be Caps lock being erroneously marked as set? Edit: Also, different window / desktop managers / (themes?) might mangle keys differently?

I did not have caps lock active.

Window managers etc. might indeed play a role, key bindings are an immensely complicated theme on X.
However, what's strange is that PS thinks that that Shift key is pressed but never released; it's hard to imagine any misconfiguration that would have that effect unless some of the keyboard event handling code inside PS is getting something wrong, too.

Sorry, I didn't mean that you had missed an LED being lit. I meant that maybe PS or the WM erroneously sets a "Caps lock active" flag (which might be called "shift" internally to PS) when eg. Rshift or Lshift is pressed. Maybe a matter of something falling through a switch(). AMOF, as you have said, relying on the WM to send sensible key values is tricky; LAlt may be called anything from (L/R)Alt, over Meta<something> to ISO_Key<XYZ>, depending on the WM (For example, Debian w Gnome vs. Puppy 3.21). So, maybe it is the case that the key press registers wrongly (say, Lshift gets mangled to Shift), while the release does register correctly (as Lshift-release), but gets discarded because ther "never was" a key press of that key.
My guess is Caps lock because (apart from the similar meaning / possible mis-naming) that is a toggle key: you need two keypresses and two releases to return to normal, so the WM or PS may do all sorts of fragile things with it, including trying to make it a modifier key instead or the other way around. If it indeed got mis-named to "Shift", then any coder not knowing of the mis-nomer may be tricked into thinking it is a key being sent when either shift key is pressed, while it behaves radically different.

I found another effect:

For example, with the "dead keys" feature activated, I can type "`" (accent grave) and "a" (letter a) to get "à". To get just "`", I can type "`" and the space bar, or "`" twice.
This works fine in every application except PS, which simply ignores the "`" key: "`" "a" will give "a", "`" <space> will give <space>, "`" "`" will give nothing.

Since that's clearly wrong, I strongly suspect that PS is mishandling keyboard input in some general way, and the Shift key mixup is just another consequence.

if you have "shift" in keyboard settings you should replace it with R and L shifts. only macosx has this bright idea of making only one the other os don't work well with that option :)

Of course. However, my speculations about where that Shift state might come from were exactly that - speculations. The facts that have been reported were:

"Clarification: After LShift-clicking inside the inventory, PS changes to the state "Shift is being pressed". It thinks so even though it is impossible for me to reproduce a "Shift" keypress (as seen in the Shortcut editing windows).
I have verified this by defining shortcuts. With that Shift state active, any shortcuts that I define will have that bogus "Shift" modifier. E.g. defining a shortcut that uses "x" will have PS tell me the shortcut is for "Shift+x". Defining a shortcut that uses Shift-X will make PS think "Shift+LShift+x" (sic!)."

This means that somehow PS creates that invalid state even on a non-MAC. And that is the actual problem, not somebody consciously adding "shift" to their options.

Edit: from your comment, we now know that there is legitimate need for PS to produce and know about this modifier. Therefore, the assumption that the necessarily very complex keyboard handling in PS is broken in that respect. Given how complex keyboard handling already is on a single platform, this is not surprising, and few applications go through the pain of supporting more than two OSes, for reasons like that, I imagine. Thus, since PS's keyboard handling has been very good for the most time, multiplatform support might well be(come) one of PS's key features. Given how often one needs to use R/L-Shift inside the inventory, this issue may bite nearly all users at some point, so addressing it would be nice, even though I'm sure this is a major undertaking for comparatively little effect.

@weltall: I have no way of controlling whether PS thinks Shift, LShift, or RShift. In fact, the left shift key on its own will produce "LShift", the left shift key together with anything else will produce "Shift+whatever". (Interestingly, this also applies if "whatever" is, say, the left alt key, that will become Shift+LAlt. If "whatever" is left alt and, say, the A key, I get "Shift+Alt+a". Seems like PS is a bit simplicistic and "normalizing" left/right modifier keys into generic ones unless they are the last on the combo. I'm not sure whether this behaviour is a feature, a misfeature, or a bug; I guess that depends on user expectations, not on anything you can find in a manual.)

I totally agree with Seytra that cross-platform keyboard handling is tricky, but I disagree that PS is doing well in this area - it works well for Windows and for the standard keyboard configurations on Linux, but from guild chat, I know that it is giving Mac users pure hell.

I'm using a Mac and I can reproducibly get any movement arrow key or the shift key stuck. Here's how:

Open up the quest window.
Click somewhere in the world (i.e. not in a window).
Hold down the movement arrow key or shift key that you want to get stuck.
Now while holding down the key, click on a quest in the quest window.
Release the key you were holding down.

Tada, you should have a stuck key now. You can usually unstick it by clicking in the chat window. You can also use the skills/stats window to stick a key, by holding down a movement key while clicking one of the skills. You can also use the backpack window, by holding down a movement key while right clicking on an item to bring up the item description.

Setting to "New", after so many replies…

There is another reated issue - when i am in running (left ctrl key function) state and I press right shift (stealth) and release it, i am not in running state anymore (i am only walking), but it's still activated, because i need to press left ctrl twice to get back into running state.