Agreed, but it may catch some errors in Gerber output generated by KiCad-nightly V5.99.
Maybe you can get still a bit closer to the real thing by asking your manufacturer to do any post processing on your gerbers and then send the result back to you for inspection. (But I’m not sure the files are still in Gerber format then).
And there is also the common practice of ordering a prototype and inspect the actual PCB. It’s also the area of previous experience with a PCB manufacturer and the trust you have in them.
Just recently I reverse-engineerd a PCB for fun (& to gain some experiene).
I had a set of Gerber files, made in an old protel program and a .pdf of the schematic.
I created a KiCad project, re-did the schematic in Eeschema, and back imported the gerbers into Pcbnew.
That old Protel program generated Zones by painting them with thin tracks, and it even painted pads as overlapping tracks. There was a 100 pin or so (Wiznet 5100 Ethernet controller) and each pad was 3 long tracks and two shorter tracks on the ends. Th manufacturer in this thread would surely have complained about that!
I just deleted all that painted stuff, imported netlist & New footprints from KiCad’s libraries, and put them on the end of the tracks that got back imported from the Gerbers.
This worked quite nice. The existing tracks automatically adopted to the netlist when real footprints were put on top of them. I made a few errors in re-creating the schematic from .pdf -> Eeschema. and these got caught by DRC because netlist and physical copper did not agree.
yeah, it is a good idea to check. for the record, I have experienced gerber-breaking changes going to 5.99 (not bugs though per se, just changes that affected my zone fills).