The current system works using an array, with one array element for each channel.

Each wifi particle checks whether there is a spark nearby. If there is, the array element for that channel is set to 1. Otherwise, if the array element for its channel already equals 1, then nearby particles get sparked.

(The actual code is slightly more complicated, since it also has to deal with turning channels off again at the right time, but you get the idea)

At no point does this take into account the locations of wifi particles relative to each other, and no indication of which wifi particle turned on the channel is stored. Hence checking whether a wifi blocker is somewhere in between the source wifi particle and a potential destination is not possible at present.

The lines between wifi are drawn by checking, when drawing each wifi particle, whether it is set to the same channel as the particle under the mouse. If it is, then draw a line between them. Graphics are done completely separately from particle interactions, so I don't think this would help much.

However, I think this could in fact be coded. More complicated than the current wifi system, and certainly slower, but should be possible:
Store the source wifi particle location when turning on a wifi channel
For each potential destination wifi particle, if the channel is turned on, check the straight line path to the source for wifi blocker (using interpolation, much like the movement code uses to check for obstacles)

But I'm not sure whether this is a good idea. TPT is quite slow enough already.

EDIT: Although there may be problems if wifi particles on the same channel, separated by blocker, are sparked at the same time. This would be particularly problematic for the original usage case for wifi blocker ("create many machines that use wifi in a single project"). I can't immediately think of a simple and non-laggy way to deal with this.