유니코드는 한 문자에 한 코드만을 부여하지 않았습니다.

글자 자세히 보시면 완전히 똑같은 글자가 아닌데요.
송효진님 말씀대로 호환을 위해서 그런것 같네요.

모두 다른 (비슷하게 생기긴 했지만) 문자입니다. Unihan database를 조금만 찾아 보셨더라면 이런 얘기는 나오지 않았을텐데요. 좀 더 자세하게 말해 보자면...

예를 들어 맨 처음 예의 U+34A8과 U+20457은 문자가 유래한 출처(IRG sources)가 다릅니다. T-source, 그러니까 대만쪽 자료에서는 둘이 CNS 11643 plane 7 0x574C과 plane 4 0x662F에 배당되어 있고, G-source, 그러니까 중국쪽 자료도 한쪽은 GB7590 0x3329이고 다른 한쪽은 강희자전이 출처네요. 더 황당한 것은 아래에 강희자전 인덱스(IRG indices의 KangXi)를 보니 plane 2에 추가된 것이 본래 강희자전에 있던 거고, BMP에 있던 건 강희자전에는 없지만 만약 들어갔다면 다른 문자로 취급되는 (제가 강희자전에서 소팅을 어떻게 하는진 몰라서 잘 모르겠지만 위치를 보니) 문자네요. 한어대자전(Hanyu Da Zidian) 쪽도 두 문자가 서로 붙어 있는 것 같긴 하지만 하여튼 다른 문자로 나오고 있습니다.

아마 두 문자는 원래 강희자전에 없는 form이 먼저 들어 갔다가 호환을 위해 추가된 것 같습니다. G-source에서 KX라고만 쓰여 있는 걸 보니 심증이 더 굳혀지는군요. 하여튼 이건 "필요해서" 추가된 거지 버그라고 할 수는 없습니다. 그리고 만약 진짜 버그면, 여기가 아니라 유니코드 쪽에 먼저 연락을 해야 하는 게 아닌가 싶군요.

(덤: 이 글에 있는 내용이 혹시 틀렸다면 알려 주시면 감사하겠습니다.)

위의 한자들의 경우에도 적용되는 것인지는 잘 모르겠지만, 어떤 한자들의 경우에는 한자 하나에 음이 2개인 경우도 있는데, 그 경우에는 위의 경우처럼 같은 한자에 두 개의 코드를 배당하는 것으로 알고 있습니다. 예를 들면, 자동차할 때, '차'라는 한자는 수레 '거'로 읽을 때도 있쟎습니까? 아마도 한자를 정렬할 때 발생할 수 있는 문제를 염두에 두고 코드를 배정한 때문이 아닌가 하는 생각이 듭니다.