When an Ethernet connection carries more than a single VLAN, all but one of those VLANs must be tagged. The IEEE 802.1Q conformant VLAN tag is placed in the Ethernet frame in the location where the EtherType of the frame would normally be. The first part of the VLAN tag is a tag protocol identifier, which is a constant value of 0x8100. As a result, a device that is unaware of IEEE 802.1Q tags or configured to not expect them will see the tagged frames and think "this is neither IPv4, ARP nor IPv6; this Ethertype 0x8100, which is something completely different and I don't think I understand it at all. Best to just ignore it."
A VLAN-supporting switch can filter packets going out to each port by their VLAN tags, and can optionally strip the VLAN tag from one selected VLAN on outgoing traffic from that port (and reciprocally add the VLAN tag to incoming traffic on that port), so that any traffic of the selected VLAN appears as plain pre-802.1Q Ethernet traffic for the device connected to that particular port. Such a selected VLAN is known as the native VLAN for that port.
The 802.1Q standard allows an Ethernet port to support a single native VLAN and any number of tagged VLANs at the same time, but I understand having a port pass both tagged and untagged Ethernet frames at the same time is a somewhat disfavored configuration: you'll need to remember that one of the VLANs in a port/NIC is different from all the others and needs to be configured differently. Prone to mistakes.
In Cisco terminology, a switch port can be configured as either an access port or as a trunk port. An access port will only provide access to a single VLAN and has the VLAN tags automatically stripped from outgoing traffic and added on incoming traffic for that port. A trunk port, on the other hand, will pass traffic on a configurable set of VLANs, but all the traffic will be VLAN-tagged.
So, to your case of two devices in two different VLANs on the same switch, both using addresses on the same IP subnet. What happens will depend on how the switch ports (and the network interfaces on the devices) are configured regarding VLANs.
1.) Switch ports as access ports, devices not VLAN-aware: the switch port will filter out the traffic of the "opposite" VLAN, and so the devices will never see each other's traffic. This raises the question whether or not it makes sense to think of them as "being on the same network segment" at all.
2.) Switch ports as trunk ports set to pass both VLANs, devices not VLAN-aware: each device will think "Why does that other device keep sending me that strange Ethertype 0x8100 stuff??? I don't speak that."
3.) Switch ports as trunk ports set to pass only one VLAN each, devices VLAN-aware: you'll need to specify the VLAN numbers in the network configuration of the devices too, but the end result is essentially the same as in case #1: the devices won't see each other's traffic.
4.) Switch ports as trunk ports set to pass both VLANs, devices VLAN-aware but configured to different VLANs: now it's the VLAN support layer in the devices themselves doing the filtering, but the practical result is the same as in cases #1 and #3: the traffic of the "opposite" device will never reach the IP protocol layer in the device's network protocol stack.
5.) Switch ports as trunk ports set to pass both VLANs, device configured with VLAN awareness, both VLANs configured in the device. This is above and beyond what you asked for. Now the device will be effectively present on both VLANs.
Since both VLANs pretend to be distinct on the Ethernet level, but are using the same IP subnet, what happens will depend on how the devices' IP routing has been implemented. The main important detail will be whether the IP stack is designed to use a strong host model or a weak host model, and exactly how the concept of VLANs has been integrated to the system.
For example, Linux will present any configured tagged VLANs as extra virtual NICs, that reflect the link state of the underlying physical NIC but otherwise act as independent as technically possible. So it will be just like you had two NICs plugged into two separate physical network segments with 100% overlapping IP subnets: the system might receive incoming traffic just fine, but will assume that any NIC connected to the destination IP subnet is good for talking to any other host in that IP subnet, and will use which ever (virtual, VLAN-specific) NIC occurs first in the routing table... and so the configuration might or might not work depending on the order in which the various parts of the NIC and VLAN configuration have been initialized. You'd need to use Linux's advanced routing functionality and create custom routing rules to handle this case well.
Using the same IP subnet on two distinct segments is a layer-3 problem, no matter what the segment separation at layer-2 is physical (= actual separate NICs) or logical (= created with VLANs). A layer-3 problem will need a layer-3 solution: using a router or some other box to symmetric-NAT one of the subnets to remove the IP subnet overlap would be much more elegant than trying to handle it at the individual devices.