MessageDeduplicationId became the MessageId after being moved to the DLQ

Thank you for the report, we are looking into this behavior.

We have confirmed that this is an intended, but not document behavior of the dead-leter queue (DLQ) mechanism when using SQS FIFO queues.

SQS supports DLQ mechanism, which sends an un-processed message to DLQ. Such process is very similar to SendMessage, so most of SendMessage constraints apply, too.

FIFO queues support deduplication id, to ensure exactly-once processing. We also use this field internally when sending a message to DLQ. As such, it needs to be a globally unique id, to make sure that the DLQ deduplication will not prevent storing of two independent messages that happen to share a deduplication id.

For example, both queue 1 and 2 are set to same DLQ. We enqueue message A to queue 1, and message B to queue 2. Both messages have same deduplication id. These messages may be sent to DLQ in the same time. If we keep the original deduplication id, only one of them will make it to DLQ - as the other will be recognized as duplicate.
To avoid this, SQS chooses to use message id, a unique id to identify them during such process, so both A and B can be enqueued into DLQ.

We will follow up with an update to the official documentation to explain this mechanism.

If you plan to use the original message deduplication id when consuming from DLQ, we suggest storing it as extra message attribute or as part of the message body.

Thank you.
I had another thread going on with the AWS Support channel for this same behavior.
Just received the answer as well, and all answered my question.