Comment 8 for bug 1605049

@jean-pierre
> Pcbnew does not yet support pad stacking.

@Novak
> Anyway the wish is rather "allowing to create different pad shapes on
> different layers" than allowing pad stacking. I think pad stacking would
> bring more headaches: how to handle overlapping holes of TH footprints,
> how to handle stacked components connecting to different nets etc...

Wow, Pcbnew is quite close to actually working, for a feature that seems to have not been intended/tested.
Based on this comment, I created a more hybrid/hack stackup, which is what users may used who need differing Size PADS top/Bottom now.

This Pin 7 stack, which first creates a Drill-slug, then adds F/B, seems to pass all DRC, but has one bug, which is the thermal-aversion effect.

    (pad 7 thru_hole circle (at -3.81 6.35) (size 1.35 1.35) (drill 1.25) (layers *.Cu *.Mask)
      (net 1 +5V))
    (pad 7 smd rect (at -3.81 6.35) (size 2.5 1.5) (layers F.Cu F.Mask)
      (net 1 +5V))
    (pad 7 smd roundrect (at -3.81 6.35) (size 3.5 1.7) (layers B.Cu B.Mask)(roundrect_rratio 0.25)
      (net 1 +5V))

Testing some more, I find that this works, (size approaches 0) and improves the thermal-aversion effect.

    (pad 7 thru_hole circle (at -3.81 6.35) (size 0.001 0.001) (drill 1.25) (layers *.Cu *.Mask)
      (net 1 +5V))
    (pad 7 smd rect (at -3.81 6.35) (size 2.5 1.5) (layers F.Cu F.Mask)
      (net 1 +5V))
    (pad 7 smd roundrect (at -3.81 6.35) (size 3.5 1.7) (layers B.Cu B.Mask)(roundrect_rratio 0.25)
      (net 1 +5V))

and then even this seems ok (size=0) - gives no DRC failures & floods/routes OK

    (pad 7 thru_hole circle (at -3.81 6.35) (size 0.000 0.000) (drill 1.25) (layers *.Cu *.Mask)
      (net 1 +5V))
    (pad 7 smd rect (at -3.81 6.35) (size 2.5 1.5) (layers F.Cu F.Mask)
      (net 1 +5V))
    (pad 7 smd roundrect (at -3.81 6.35) (size 3.5 1.7) (layers B.Cu B.Mask)(roundrect_rratio 0.25)
      (net 1 +5V))

It may 'look' a little strange/counter-intuitive, it DOES seem to pass the DRC, and flood connect ok, and route ok !!.

The Thermal aversion effect is still there, and if you look carefully you can see Pin7.F.Cu has thermals that pull-up-short inside the drill.
(aversion effect here, seems to not be to the Drill, but the 0 size pad on *.Cu, which is needed to pass the DRCs)

I think if Cu clearance is always < PAD/2 this will be ok ? Should be true in most cases, leaving only rare thermal failures.

See attached test case, with attention to Pin7, that seems a workable hack ?

Even with this level of PADS stack support, KiCad looks usable, but I would describe that Thermal-aversion as a bug, as Thermals/Fill really should NOT be averse to the SAME NET entities.
ie Fill floods over traces fine now, & it should work equally _inside_ any PAD footprint.

That is probably simple to fix, as what it does now is superset-complex.
'Same Net' trumps entity found should fix it ?

Maybe this can change to a Thermal-aversion bug ? (given the stack workaround looks ok ?)