Premove buggy, cost me the game. Goooooood.

@forkedyourqueen said ^

Well I've certainly stirred up the Lichess community, but I appreciate the feedback (and the 3 losses) Knakkert
Factually, there are two ways to handle that situation. Option A and Option B, Lichess chose Option A. I merely suggested the ...
the user should be given the option to choose either A or B. As it's not a chess rule, but a UI choice.

Would you agree that a online chess platform should follow the rules of chess?
If you agree, we should find out which rules are valid. I suggest Lichess follows the FIDE rules. ok?

What does FIDE tell us about the definition of a move? "3.1.4 As a minimum, the playing zone must offer the player having the move the possibility to select the source and target squares for the move."
We remember the word "square". Square not purpose.

What about FIDE and Pre-move? "3.1.5.2 Pre-move: the player enters a move before the opponent has moved. The move is automatically executed on the virtual board as an immediate response to the opponent’s move unless the move is illegal."
Again: Square not purpose.
FIDE ONLINE RULES: https://handbook.fide.com/chapter/OnlineChessRegulations

So its following the rules and not a design decision.

@Viohl said ^

So its following the rules and not a design decision.

FIDE’s online rules already contain design decisions about which mistakes players are protected from.

• Block illegal moves, sparing you the penalties for completing one over the board. (Design decision written as a rule.)
• Let you choose another piece after a rejected attempt. Over the board, you still have to move that piece if itcan move legally, even if that means losing it. (Design decision written as a rule.)

I suggested another optional protection: cancel a premoved capture if its target moves away. Protection already exists; I’m questioning where it stops.

If FIDE ever decides to revisit its legacy list of design decisions written into the rulebook, I’ve already suggested where to start.

@forkedyourqueen said ^
...

Factually, there are two ways to handle that situation. Option A and Option B, Lichess chose Option A. I merely suggested the ...

It does UI-wise look like premoving anything onto an existing piece will always be a capture, when it only is unless the piece in question is moved. (Moves might be captures, but look like they always are, as the premove is made before the opponents turn to move.)

Defaulting to using the "move" colour for all premoves is easy enough.
Differentiating from that by keeping with the "takes" colour-scheme only for discovered captures (opponent moves something out of the way so as to allow it) is a bonus.

For new players, the difference between the premise of those two premoves is not obvious, so it can't follow that the new user gains any confidence in what works sometimes as intended on part of the user.

Quite sure I did the exact same thing to find out, as I was aware the same colour is used.

What do you mean by "You should've accepted the takeback"? Let the opponent play the game in peace.