Thanks ramhuliyar for your observation. I just checked it with a sniffer and indeed it seams that the "identifier" field that is being translated NOT the "sequence number".
[code:1]R3#debug ip nat det
IP NAT detailed debugging is on
R3#
00:23:04: NAT*: i: icmp (192.168.0.2, 1024) -> (172.16.1.1, 1024) [37792]
00:23:04: NAT*: s=192.168.0.2->172.16.1.10, d=172.16.1.1 [37792]
00:23:04: NAT*: o: icmp (172.16.1.1, 1024) -> (172.16.1.10, 1024) [514]
00:23:04: NAT*: s=172.16.1.1, d=172.16.1.10->192.168.0.2 [514]
00:23:05: NAT*: i: icmp (192.168.0.2, 1024) -> (172.16.1.1, 1024) [37796]
00:23:05: NAT*: s=192.168.0.2->172.16.1.10, d=172.16.1.1 [37796]
00:23:05: NAT*: o: icmp (172.16.1.1, 1024) -> (172.16.1.10, 1024) [515]
00:23:05: NAT*: s=172.16.1.1, d=172.16.1.10->192.168.0.2 [515]
00:23:06: NAT*: i: icmp (192.168.0.2, 1024) -> (172.16.1.1, 1024) [37810]
00:23:06: NAT*: s=192.168.0.2->172.16.1.10, d=172.16.1.1 [37810]
00:23:06: NAT*: o: icmp (172.16.1.1, 1024) -> (172.16.1.10, 1024) [516]
00:23:06: NAT*: s=172.16.1.1, d=172.16.1.10->192.168.0.2 [516][/code:1]
1024 was the identifier shown in the sniffer both inside and outside, and it's obviously shown above. However, I wasn't able to verify the case were 2 hosts send with the same inside identifiers. I did a test on it but the router on NAT never changed any identifier on the out side. They remained 1024 as shown above!!!. And by the way, those numbers between brackets are not the sequence numbers. I'm guessing I could not send the ICMP pings exactly at the same times. If I assume that it was depending on sequence number difference from the two hosts when the identifiers matched. Then this means the router would need to translate and store the "sequence number" in it's translations table along with the "identifier", which I doubt.