I can see nothing wrong, except the “zero length track” but that is apparently not the issue.
I took some of your numbers, and gave them names:
(You can check these numbers with your file, and paste them in a python console thingy, octave, etc)
XXX = 92.974013
X_W = 0.15
EBI = 0.115
CLK_X = 93.374
CLK_W = 0.42
Then I calculated the width of the stack:
End = XXX + X_W/2 + EBI + CLK_W/2
End
93.37401299999999
And calculated the overlap:
CLK_X - End
-1.2999999995599865e-05
So you have an overlap of 13um and DRC is right.
To double check, I clicked on the “zero length” track, and e to edit it’s properties, and moved it an extra 13nm to the left:
And with this 13nm push DRC is happy because there is no overlap anymore.
How important is this overall feature to you?
In KiCad-nightly V5.99 there is a an option to remove pads from inner layers if there is no track connected. It’s not a full pad stack yet (were each layer can have it’s own pad size) but it is a step in the right direction. But before you dive into that, read: Is it a good idea to use a nightly build version?
Some time ago there was an issue on gitlab, concerning rotated footprints which caused DRC errors. (for example 0.5mm pitch QFP with 0.3mm wide pads and 0.2mm clearance. The solution was to add a tolerance for DRC of a nm. (Yep, nanometer) and that was deemed enough.
P.s:
Excuse the repetitive digits. It’s rounding error from Pythons floating point stuff. KiCad itself works with 32-bit integers in nanometer resolution (so a max PCB size of 4 * 4 meters)