The escape sprite handling glitch (coined by Pigdevil2010 as the Escape Rope sprite handling glitch) is a natural glitch in Pokémon Red, Green, Blue, and Yellow.
When the player uses Teleport, Escape Rope or Dig to escape from an area outside of Super Game Boy or Game Boy Color mode (however, a Game Boy Color or Game Boy Advance playing Pokémon Red and Blue is apparently fine), the player's sprite may temporarily be replaced with a flipped "ABCD" square in English versions, or a flipped "アイウエ" square in Japanese versions during the escape animation.
To display the Start menu, the game needs to load the tileset used for text, which overwrites half of the tileset used for overworld sprites. Specifically, the "walking" frames of sprites are overwritten. NPCs respond to this by reverting to the "standing" state whenever the tileset for text is loaded. The player sprite does not check the tileset, but normally it's impossible to open the Start menu (or display any sort of text) in the middle of a player step, so it's not a problem.
The problem comes from the code that handles the animation of the escape item. The player is supposed to first spin in place for a while, then start to move up while continuing spinning. For both parts of the animation, the function SpinPlayerSprite is used to change the facing of the player. That function assumes that the 4 byte list wFacingDirectionList has been initialized to some cyclic permutation of $00, $08, $04, $0C (down, left, up, right), with hl pointing into somewhere into the list. This is indeed the case for the first part of the animation.
However, for the second part of the animation, hl is erroneously left pointing to somewhere else, namely, wPlayerSpinWhileMovingUpOrDownAnimFrameDelay. This value is explicitly set to 2 on SGB, and 3 otherwise. Therefore, SpinPlayerSprite would futilely shift wFacingDirectionList around, while setting the player's facing byte to $02 or $03 depending on the platform.
("Facing values" that are not a multiple of 4 are used for the walking animation, which consists of 4 frames. For walking down, those are standing, walking, standing, walking and flipped (to "move the other foot"), corresponding to $00, $01, $02, $03 respectively.)
On SGB things seem fine, because $02 is just another name for $00 (facing down, standing), so the player just move off the top of screen without spinning. On other platforms, however, the facing byte is set to $03 (facing down, walking, flipped), but the corresponding tile has been overwritten, and hasn't been reloaded yet. Therefore the sprite is displayed as a flipped "ABCD" square.
The same programming error happens when the player arrives at the warp destination; however, by that time the tileset is already properly reloaded, so the player just drops to the ground in a walking posture (non-SGB platform) or standing posture (SGB) without spinning.