Why are Zen insisting when they check that there is no crosstalk?
Zen are probably referring to the GEA Service Test run by Openreach which looks for obvious signs of REIN, Bridge Taps and Cross Talk based on your line stats, Hlog and QLN.
They will pick up very obvious and acute instances of certain tyes of errors depending upon steepness and repetitiveness of plotted curves.
As regards to Cross-talk, there are 3 types of crosstalk: NeXT, FeXT and Alien noise.
Most of the reduction of speed over time on FTTC is due to FeXT. Its sometimes often hard to see on QLN graphs and can take a trained eye to spot, because it usually causes a very shallow dish like effect in the bit load graph. If you have a neighbouring line using similar tones to you, then you will both likely be using the same frequencies so nothing that much obvious shows in the graphs. You spot it most when they go off line or resync as its effect is a rapid change in the SNRM. It's easier to see crosstalk from neighbouring adsl lines as the dip tends to bottom out where the adsl reach tones ends.
FeXT affects the shortest loops the most... and this is very true when it comes to what we mean when we talk about crosstalk. Those lines which previously syc'd at 80Mbps are the ones which lose the most speed to crosstalk.
NeXT (nearend) is usually very local - its the 'home end' eg in your own cabling/copper pair. I'm not certain on this, but I 'think' it's NeXT that the GEA test picks up on.
I most definitely am badly affected by crosstalk, yet the GEA test always shows "Not Detected" for Crosstalk.
There is nothing Openreach can do about FeXT (bar using vectored DSLAMs), so if you are affected then its just bad luck.
I'm quite happy if for you to go back to Zen and say that the GEA test doesn't detect FeXT (Far End Crosstalk) because its true. But then again there's stuff all they can do about it either