Because it's not encoded in a valid way.
a valid private key is just a number below
115792089237316195423570985008687907852837564279074904382605163141518161494337
which you convert to a WIF by adding version, checksum, compression, and base58 encoding.
So
c8732e48be68ee2f0792f8c428337dafd6066ae5f2a5d86ae81e48e14b4c755f
for privkeys, we add 0x80 as version, we double SHA256 it to get the checksum, and then encode it appropriately.
So, adding <version><key><compression?>, we get
80 c8 73 2e 48 be 68 ee 2f 07 92 f8 c4 28 33 7d af d6 06 6a e5 f2 a5 d8 6a e8 1e 48 e1 4b 4c 75 5f 01
Because we want the compressed pubkey, we add 0x01 to the end.
Double SHA256 it, we get
6a 45 c1 63 58 6f 23 c6 1d ef 89 f5 0b 16 38 96 67 f0 32 67 48 ae b9 58 c3 fb cb 8e 08 3c 79 d9
concat the first 4 bytes to the encoded buffer, so we get
80 c8 73 2e 48 be 68 ee 2f 07 92 f8 c4 28 33 7d af d6 06 6a e5 f2 a5 d8 6a e8 1e 48 e1 4b 4c 75 5f 01 6a 45 c1 63
now base58 encode it, and you get
L3wMo5Z7UdvqTRmTRAjtowUAqDrKmKpvuWbLZtgFkmWvT6cW7xDG
As stated above, changing any of the characters in the resulting string invalidates the entire key.
Why, you may ask?
Decoding
L4wMo5Z7UdvqTRmTRAjtowUAqDrKmKpvuWbLZtgFkmWvT6cW7xDG
results in
80 e6 49 8d e8 4c 1e 5e 7f 4c e2 60 ab 37 6f f4 85 68 3a 32 07 04 a4 01 28 7d fa 27 12 2b e0 99 5f 01 6a 45 c1 63
for which the calculated SHA hash is (remove original checksum first!)
f2 b5 8d 69 d8 d7 f4 84 04 0c 5d d5 97 c7 5b fa a8 94 ac f9 ca e0 a7 5e 83 01 b3 bf 79 19 80 9e
As you can see, the first 4 bytes do not match.