Limitations of Resource Access Manager

A subnet is part of a VPC (Virtual Private Cloud) and the route tables of a VPC determine how traffic is routed between subnets within that VPC.

In your example, Subnet-A is owned by account A and is part of a VPC in Account A. Subnet-B would be in a separate VPC owned by Account B. When shared, Account B could launch EC2 instances into Subnet-A, but its existing Subnet-B would be unaffected.

Regarding differentiating between resources, all AWS resources (i.e. Subnets and VPCs) have unique IDs. A CIDR is just a property of a Subnet, it is the Subnet's unique ID that you select when launching an EC2. So, sharing a subnet with the same CIDR as one that already exists will work in that you can launch an EC2 instance into either that account's original subnet or the shared one by specifying the correct subnet ID when you launch the instance.

Regarding what happens for traffic from/to EC2 instances, that is determined by the route table of the VPC in question. The original subnet and shared subnet will be tied to different VPCs with different route tables. Resources launched into separate VPCs cannot talk to each other without VPC Peering set up and route tables adjusted.

Therefore, in your example, EC2-A and EC2-B will not have any connectivity by default, as they're both running in different VPCs. All traffic they send will be bounded to their respective VPCs and any EC2 in one subnet won't be able to talk to the other.

If the CIDR ranges did not overlap, you could set up VPC Peering between the two VPCs and adjust the Route Tables to allow the two subnets to send traffic back and forth, but since your CIDRs overlap, you cannot do this.

Regarding your second question, you may want to read VPC Sharing: Key Considerations and Best Practices