...which mechanism ensures that when you send a request at location A
that has IP address 6.7.8.9, you won't receive a response with also a
few packets delivered at location B that has IP address 6.7.8.9 and
another few packets delivered at location C that also has IP address
6.7.8.9?
That's really the point of anycast. When you send something to an anycast IP address, the routing protocol will route the traffic to the nearest (according to the routing protocol) network for that address. If there is a problem where a link to one of the networks goes down, the traffic will automatically be rerouted to the next nearest site. You, as the sender, don't care which one gets the traffic. That's why it is so useful for things like DNS and NTP.
It's not like an individual can just start advertising a network on the public Internet. Someone advertising a network on the public Internet better own that network. If you have a BGP relationship with ISP(s), they will find out if you are advertising a network you don't own, and you will be summarily cut off from BGP peering with the ISP(s).
Anycast is also used by CloudFlare for the content delivery network,
which would be HTTP(S) over TCP and not just UDP Packets. If you are
in middle of uploading some data and the data get scattered over
different servers, would the only option be retransmitting it and
hoping it goes to the right server next time or does anycast have an
option to prevent this?
TCP cannot get scattered over different servers. TCP is a connection-oriented protocol, and it creates a connection. If a link to a server to which you have a connection goes down, you would need to create a new connection to the next server in line. Anycast is nothing more than using the routing protocol to get the traffic to the nearest network with that network address.
If anycast is used and if the path to server A is the shortest path
for one fraction of a second and then the path to server B is the
shortest path for another fraction of a second and then the path to A
is the shortest again for another fraction of a second, etc. it would
get scattered over different servers. It takes several seconds before
it goes to the timeout state and TCP would require several
retransmissions attempts to be made before it goes to timeout.
That would be a serious network problem if the routing changes that often, especially on the Internet. BGP will notice flapping, and it will penalize the flapping link, and the link will get dropped from routing updates. You would be hard-pressed to find what you fear in the real world. ISPs take stability very seriously, and they will block partnerships which display instability.
How about this scenario: Server A and B have the same IP address with
anycast. Server B connects to an external server that is very close to
server A and very far away from server B, since server A is closer,
the response will be routed back to server A, isn't it possible to
always route this type of requests back to server B, since server B
initiated the connection to the external server?
You are really trying to make this a lot more complicated than it is. You don't initiate a connection from an anycast address to any old address on the Internet. Anycast addresses are destination addresses. If a host with an anycast address needs to contact a different host on the Internet, it uses a non-anycast address, either with a secondary address on the interface, or, more likely, a different interface. Don't confuse the anycast address with the host itself.
Seriously, there are some very, very smart people who do nothing all day but think about this sort of thing. RFCs must be peer approved before they are released as proposed. If nobody has any real objections, they are promoted to RFCs. The whole world has these under a microscope from the very inception of the idea, through, and after the release of the RFCs. If there really was a flaw in anycast, it would have been discovered, and solutions proposed, years ago.
There are multiple RFCs for anycast: RFC 1546, Host Anycasting Service (November 1993), RFC 4786, Operation of Anycast Services (December 2006), and RFC 7094 , Architectural Considerations of IP Anycast (January 2014). These RFCs will explain how Anycast works.
