Two valid WIF's for one public address. Why?

I have a private key that is valid but I don't understand why. This is a long post so bear with me. Note: this address is worthless.
The below is a full key. Version 76.

Code:

3081d30201010420ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54a08185308182020101302c06072a8648ce3d0101022100fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f300604010004010704210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798022100fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141020101a12403220003c0ef03fc45624122c85791557be9782cc7a2a813125f317aa0136b25ce5cec76

Code:

ehco -n "3081.." | xxd -r -p | openssl asn1parse -i -inform DER -dump

 0:d=0  hl=3 l= 211 cons: SEQUENCE          
    3:d=1  hl=2 l=   1 prim:  INTEGER           :01
    6:d=1  hl=2 l=  32 prim:  OCTET STRING      
      0000 - ca 7b 50 f4 1b 2f 43 e1-e9 13 bd b6 f6 ff 32 89   This is the private key. 
      0010 - 22 3d 9e c0 eb e6 10 f8-01 a1 e9 3c b2 56 4d 54   //ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54
   40:d=1  hl=3 l= 133 cons:  cont [ 0 ]        
   43:d=2  hl=3 l= 130 cons:   SEQUENCE          
   46:d=3  hl=2 l=   1 prim:    INTEGER           :01
   49:d=3  hl=2 l=  44 cons:    SEQUENCE          
   51:d=4  hl=2 l=   7 prim:     OBJECT            :prime-field
   60:d=4  hl=2 l=  33 prim:     INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
   95:d=3  hl=2 l=   6 cons:    SEQUENCE          
   97:d=4  hl=2 l=   1 prim:     OCTET STRING      
      0001 - <SPACES/NULS>
  100:d=4  hl=2 l=   1 prim:     OCTET STRING      
      0000 - 07                                                .
  103:d=3  hl=2 l=  33 prim:    OCTET STRING      
      0000 - 02 79 be 66 7e f9 dc bb-ac 55 a0 62 95 ce 87 0b   .y.f~....U.b....
      0010 - 07 02 9b fc db 2d ce 28-d9 59 f2 81 5b 16 f8 17   .....-.(.Y..[...
      0020 - 98                                                .
  138:d=3  hl=2 l=  33 prim:    INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
  173:d=3  hl=2 l=   1 prim:    INTEGER           :01
  176:d=1  hl=2 l=  36 cons:  cont [ 1 ]        
  178:d=2  hl=2 l=  34 prim:   BIT STRING        
      0000 - 00 03 c0 ef 03 fc 45 62-41 22 c8 57 91 55 7b e9   This is the public key. Exclude the first byte.
      0010 - 78 2c c7 a2 a8 13 12 5f-31 7a a0 13 6b 25 ce 5c   //03c0ef03fc45624122c86791557be9782cc7a2a813125f317aa0136b25ce5cec76
      0020 - ec 76

Above here is an asn1parse of the full key.
Doing such reveals that "ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54" is the private key.

Now, I'll convert it to WIF. (wallet import format)

Code:

1.)For 76, add '4c' to the front of it, and '01' to the back. (01 for compressed keys)
2.)SHA256sum it. "echo -n '4cca7b...' | xxd -r -p | sha256sum
3.)SHA256sum the previous result once more. 
4.)Take the first 4 bytes from the result (8 characters) This is the checksum.
5.)Put the checksum at the end of step 1. The 4c....01 string[checksum].
6.)Convert it to Base58. This is now your WIF format.

S0.) ca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d54
S1.) 4cca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d5401
S2.) 54f1aa00273e23379fc4a08ad08b918d7e97b6ff1ebfa097350fb93dffdd00e6
S3.) 17f77291600662c7c2d7ae3969172dda3ec1885bdac75c356ba3dee94b4ce305
S4.) 17f77291
S5.) 4cca7b50f41b2f43e1e913bdb6f6ff3289223d9ec0ebe610f801a1e93cb2564d540117f77291
S6.) CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G

The above converted the private key to WIF format of 'CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G'.
Which is valid for the public address of "Xf5QNbxmxtBRK1BXY5yYNYZCJuugX5ro6v".

______________________________________________________________
Now this is the part I don't understand.
______________________________________________________________
The WIF format is valid and returns the correct private key for this address but it's completely different! (yet valid)
The above WIF when ran through pywallet returns 'XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3FW' as the private key. Which does return the public address I was working with.

Why does 'CMRX8....' translate to 'XJ5EKW...' and why didn't it return 'XJ5EKW....' when I completed the previous steps?

Basically, why are "XJ5EKWJQkxRENadpJAXoN4UJ3r3TN4mqn1UB8ecckBgSXnmFF3FW" and "CMrX8rBGMH9deLwVWU1VTnMxCEKxWW4nwTjVWWGVtwDLVRF6vg4G" both valid and different private keys for the public address of "Xf5QNbxmxtBRK1BXY5yYNYZCJuugX5ro6v"?

Summary

There are two valid Private WIF keys for the same public key. Why?