We need precise control over the entity age and ID for this to work, so sources of interference are generally unexpected entity spawns that mess up the ID.
Recall that any entity spawning will increment the ID counter, and the full list of entities is surprising. An exhaustive list is available at The Minecraft Wiki.
In general, the solution is to spawn our item entities at nearly the same time, so there is no chance for other entities to spawn in-between. For example, by spawning all items with droppers in the same game tick, all the items are created in the same tick phase, so player inputs and world events cannot affect it. See Section 3 for details.
In singleplayer worlds, there are separate execution threads for the renderer and game world. The game world (“server thread”) contains the item entities we care about for the purposes of EID Wireless, as these are the entities we can detect with redstone. However, the renderer (“client thread”) also tracks some entities.
In versions before 26.2, there was a bug (MC-238384) that caused the client thread and server thread to use the same global ID counter. Therefore every entity might increment the counter twice: once when it spawns in the server, and once when the client begins to track it. Because this depends on the position and orientation of the player, and also on the unpredictable scheduling of the two execution threads, it is impossible to truly compensate for these effects.
The solution is to either use a dedicated minecraft server, so that the client and servers run in separate processes, or install a mod that patches the game to use a separate counter for the client.
There are also several mods that fix this functionality in some versions before 26.2
Most recent versions of Paper server are compatible with EID Wireless. However, Paper 1.16-1.17 included a different stationary entity optimization from Spigot (Paper #6277) that corrupts this.
When a chunk unloads and reloads, all entities contained within it are destroyed and recreated with new entity IDs. Therefore any information encoded in the ID group offsets is destroyed.
When a chunk containing an EID Wireless receiver is reloaded, every in-progress transmission MUST be discarded.
The best thing to do is to use a reload detector and lock the receiver output for one full cycle after a reload.
Entities in lazy chunks do not age or move, and their IDs are preserved. However, the redstone circuitry will continue to function. If a chunk becomes lazy while a transmission is being processed, the detection circuits will not observe the right drop delays and so the transmission is corrupted.
When a chunk containing an EID Wireless receiver becomes lazy, every in-progress transmission MUST be discarded.
Further, depending on the receiver design, there is a small chance the items become clipped into blocks. When the chunk becomes entity-processing again, the clipped items will fly out of the machine instead of being recycled.
The best thing to do is to use a chunkloader to prevent the receiver ever being lazy-loaded. If chunkloaders cannot be used, a lazy-chunk detector can be used to lock the outputs while the chunk is lazy-loaded and for one full cycle after it becomes entity-processing.