TXIDs of unconfirmed transactions can not be trusted to stay the same. <-- We saw what that one did very recently.
If ECDSA requires a RANDOM number, you better make sure you actually use a random one. <-- We had that one too (aka. Android bug).
Any other "long known" wiki articles with things that are likely being overlooked by client implementers or people using the RPC API?
Examples could be some more exotic script types, chain reorg detection, relaying (or not relaying) as well as reporting double-spend attempts, dust spam/collection, some more intricate crypto stuff...
If ECDSA requires a RANDOM number, you better make sure you actually use a random one. <-- We had that one too (aka. Android bug).
Any other "long known" wiki articles with things that are likely being overlooked by client implementers or people using the RPC API?
Examples could be some more exotic script types, chain reorg detection, relaying (or not relaying) as well as reporting double-spend attempts, dust spam/collection, some more intricate crypto stuff...
Yes, I have a similar idea that we should list out all these "known problems" and put them on the top of our agenda.
If something is exploitable, someone must exploit it (e.g. malleability)
If something may go wrong, someone will certainly do it wrong (e.g. random number bug)
For the issues you listed, chain reorg could be a big headache with this ongoing malleability attack. In case we have a chain fork like the Mar 2013 one again, many transactions will get orphaned due to their parents are mutated.