Transaction malleability can affect two major things: wallet software, and contracting protocols.
There are two kinds of transaction malleation: 3rd party malleation, and 1st party malleation. In 3rd party malleation, anyone can change a transaction's id by modifying parts of it that are not covered by a signature. This includes the signature itself. In 1st party malleation, the transaction ID is modified by the sender(s). This is trivially done by re-signing the transaction but using a different nonce in the signature.
While malleation is modifying a transaction so its txid changes, a different way to view it is a transaction that double spends the original but happens to send the Bitcoin to the same outputs. This is how nodes and wallets view the transaction, there is nothing special to mark transactions as being malleated nor does there need to be, they just look like and should be treated as double spends. Additionally, malleation is only an issue for unconfirmed transactions. Once a transaction confirms, the block commits to the transaction ids of all of the transactions in the block so there is no "show a different transaction ID". Again, these must be considered as double spends because that's what they are. There's really no "original transaction" or "modified transaction", they're two distinct transactions that conflict with each other (spend the same inputs), that just so happen to have the same outputs.
Malleability first became a noticeable issue when wallet software would have issues because of malleated transactions. Back then, wallet software in general was not very good at handling double spends. This would result in issues such as wallets thinking they had access to more coins than they actually did, wallets continuously displaying and trying to rebroadcast conflicts that are no longer valid, and wallets trying to spend coins that no longer exist. These are all generally annoyances but shouldn't be the cause of significant concern, and they aren't unique to malleated transactions, any double spending could result in these issues. But since anyone could malleate a transaction, these annoyances could be done on a large scale by a single person. This is generally no longer an issue as wallet developers are aware of transaction conflicts and have made changes to their wallets to deal with them more gracefully.
Transaction malleation was also noticed to be a major hindrance in contracting protocols such as Lightning. These protocols rely on the transaction ID not changing as they are pre-signing transactions that refer to a transaction that has not been broadcast yet. If the first transaction is malleated, and the counterparty is not cooperating (perhaps they malleated the first), then funds could be lost. Resolving these issues so that such protocols can work would require a solution that removes both 3rd and 1st party malleation.
There were a couple of attempts to remove malleation. BIP 62 was one of them. It tried to enumerate many different malleation techniques and essentially outlaw them. However this is not necessarily a good solution since it still allows malleation in ways that may not have been thought of. So it was withdrawn.
Segwit is different from BIP 62 in that it resolves the vast majority of malleation issues by removing most things that could cause malleation from the txid calculation itself. Segwit made it so that signatures, scripts, and stack items are all stored in a separate part of the transaction which everyone would ignore for the purposes of transaction id calculation. It further does this only for a subset of scripts so that it can remain backwards compatible. In this way, instead of figuring out what could be malleable and explicitly enumerating them, it just takes everything that could be malleable and puts it somewhere else. However Segwit is not a perfect solution, things that were malleable previously still are malleable, you have to opt-in to using Segwit and non-malleability. Furthermore, there are still ways to make segwit things malleable, but they basically require trying to make things that are malleable rather than malleability being the default as with non-segwit.
5. Could transaction malleability be used against old transactions to stop quantum computers attacking address which has exposed their public key?
No. Malleability does not apply to anything that's confirmed and it does not actually hide anything.
