The primary problem in this case is not a security one first and foremost; this situation creates apparent packet loss, as the link layer protocol mapping for your IP address will typically change between you and the other node according to the action of a race condition and much traffic will not go to the requestor. Of course, this does all depend on the link layer.
It's certainly possible that you would see some of each other's traffic, and if you were malicious you could certainly dump it. Of course, you would probably not get all of it. However, this is no different from viewing traffic in transit through a mirror port or by getting it out of a router or something - it wouldn't make it any easier to break the security of SSL sessions, for instance. So, even if this happened (and it would indicate severe incompetence on the part of the ISP), I would not expect an actual security breach unless I wasn't encrypting things.
You'd also see the return traffic of the other person, but not what they send.
In practice, when there are duplicate IPs like this on an ethernet and the nodes do not detect and handle the failure, it's basically impossible to complete the TCP 3-way handshake (let alone negotiate a TLS session) and the connection looks to be extremely poor or entirely down.
Most differences would be as a result of the link layer and how it maps link layer addresses to network addresses, and most security differences would be a function of the application layer protocol being used and whether IPsec is in use. In IPv6, since you are assigned a prefix and that is what would have to conflict, the consequence would be almost identical except that there isn't likely to be anyone on your network with the same IP as the misdirected packets are destined to.