People have been talking about Pay to Anchor for some time, but it's formal specification has recently been merged into the BIP repository as a draft BIP.

P2A is a special output designed to help people who have lightning channels avoid pinning attacks.

In lightning, if your channel partner can try to cheat you by closing the channel and broadcasting an old state. If this happens, you need to broadcast the more recent state and get it included in a block before their transaction is included in a block. If your channel partner is particularly devious, they may try to pin the transaction you broadcast by taking advantage of node protections against attacks that can waste bandwidth, CPU, and memory. If fees have risen since you last agreed on the state of your channels, they may be able to prevent you from increasing the fee on your transaction via RBF.

P2A is an attempt to solve this problem.

P2A is just a small, keyless output type that makes it easy and cheap to CPFP a transaction. It does not enable 0 fees, packages, or ephemeral dust. It also does not need to be used in conjunction with 0 fees, packages, or ephemeral dust. You can create a P2A output in a transaction mined by itself, then spend it many blocks later (this has happened).

If you add a P2A output to your lightning commitment transaction, you can later fee-bump this P2A output (and therefore the whole commitment transaction).

P2A outputs have been around for a while (a year or two?), and BIP 433 is not describing a change to block validation rules. Instead, it's a case of making mempool policy rules work better for people who have Lightning channels.

If you are interested in learning more about P2A outputs, this stack exchange question has some very detailed answers. There is also this BItcoin Optech topic page about P2A.