Ah, yes, now I follow
Your update is locally correct, but if you want it to also remain correct after a NET import, (which is a good idea) then you will need to clone the Auto-Generate selection used by SCH netlist generate.
You could get the eeschema source and see how they choose the seed ?
Fingers crossed it is ref-des based and not sheet-placement based.
Unfortunately, the KiCad code is written in c++, which I am not good at, and almost entirely undocumented so it would be an enormous amount of work to reverse engineer.
I will wait for further feedback before determining how big a problem this is, especially as it is so easy to correct in KiCad’s PCB application.
I will make a not to strip file extensions in a future edition. I am really keen to hear what Andy thinks because he seems to have a complicated design with channels, etc…
Thanks again
The help menu needs mentioning that complete paths should be put in parenthesis, otherwise it won’t deal with spaces in folder/file-names.
For me it also didn’t want the extension there (had tested with test.sch and test.kicad_pcb but in each case it couldn’t find test.sch.sch or test.kicad_pcb.kicad_pcb).
Besides that it seems to work. 
Win7 64bit
KiCAD BZR6971
sheet structure:
2 layer board with 247 devices (21 different designators) placed on front and back
Ran it with options -m and -v.
Good job on ignoring things like mousebites (with REF** for example) that have been placed in PCBnew 
I had 2 devices in the schematic that I removed in PCBnew and got two warnings like this for each:
Schematic refdes xyz not found in change array!
No idea if that warning also covers other cases, but that’s what triggered it for me.
Sweet!
Beats doing it by hand, right. I run about 300 mSec on a complex board.
Yes, the PCB is annotated first so it builds the change list from the PCB. Then it goes back and changes the schematics. If the schematics have changed it will flag those as errors. I put this in for debugging but I guess it can be helpful to show the database is out of whack.
Thanks for the feedback!
So far I haven’t had the desire or need to do this kind of thing (populated above board for the first time by hand 2 days ago), but your program does such a nice job I’ll definitely use it in future (as I found I was hunting around the printed assembly layout in the search for device XYZ way too often). 
I used to be an electronics designer (not a PCB designer) My last board I designed professionally had about 400 components. You can imagine tracking down R61 if they aren’t in order.
Then imagine a modern board with 1000 components on the front and back …
With my software you can label all the back components B_R61 or whatever.
I am pretty sure professional packages do this automatically so I was surprised KiCad doesn’t.
I ran a quick test, and tried R1,J2, which gives “Net-(J2-Pad9)”
then a flip of R1 to A1, no other changes in placement or wire order, then gives this :
(net (code 8) (name "Net-(A1-Pad1)")
(node (ref A1) (pin 1))
(node (ref J2) (pin 9)))
appears to be a simple ASCII sort ?
I tested rename based on starting letters of 0 <- : <- A <- J -< a
A002 <- A1
A1 <- A100
A001,A1 complains for re annotate, as it seems to resolve those as the same.
I think the problem is that PCB deals with that sort of things as being “normal”. So it says "hey - here is net A2-Pad1 but it connects the same as J2-Pad9 on the PCB so I’ll load it and call it J2-Pad9.
However it doesn’t appear to subsequently remember to do the same with filled zones.
So it sees a new net which connects to many of the same things as J2-Pad9, but not all the same things (because of the zone) and it doesn’t rename it. Then it flags the two as separate.
Are you sure ? I’ve never seen that specific rename of a valid, provided net-name.
(I have seen that net Name trumps net number )
I am not sure of anything. However the PCB and schematic files are fine until a netlist is imported. PCB seems to handle all the other renamed nets (but I haven’t checked all of them) except one where there is a pour.
If you look at before/after netlists they are similar but different. Sometimes net names will change sometimes the order nets are listed changes.
I think the problem is with how PCB handles net imports with pours and may be reproducible just by messing with the schematic.
None of this is really documented so it is not trivial to figure out.
Looks to me like you are very close.
The NET import knows nothing about Pours, so it is not surprising that needs your extra pass.
However, once that is done, the other effect is Auto-name re-seeding, and that seems to be by simple sorted Ref-name.
It does mean you need to collect the new set of RefDes for each net, and then re-seed after any part-renum.
I also note
“Net-(J2-Pad3)” <- “Net-(J2-Pad5)”
so the simplest would likely be a list of possible auto-names, based on all present nodes, and then sort & pick first.
You could even generate a exPCB NET file, as that is something PCB side does not currently do, and a NET file is a nice way to confirm nothing was added/lost in revisions.
You can compare that with the SCH NET, to confirm your seed is the same.
I would like to know the current project works and people use it before expanding the scope of the project.
I can replicate the problem exactly without using my software on the original design.
Edit the ref des of L4 (power supply page) and C67 to L1004 and C1067. Do the same on the PCB (i.e. manually annotate the PCB/Schematic. Generate and import the netlist and exactly the same problem appears.
So it appears sometimes PCB does not properly handle netlists when there are pours involved and the netlist names change.
Yes, I’d say the KiCad PcbNew is importing NET info in a simpler manner.
If there is a Pour inside PCB that is Auto-Name tagged (somewhat rare, but possible), then any time a renumber shifts that Auto-named NET, you will have issues.
User-named Pours will be ok.
The NET file would need something like RENAME NET command, to cover this, instead it rebuilds a connection tree, and does not ’ go looking for’ other info to track this change.
That’s probably tolerable, as the workaround is possible.
You SW can raise the IQ of this whole process, if it does more of the housekeeping.
It already renames Pour areas, but does not (yet) track SCH auto-name seeding, so you can expect diverge when you import a new NET from renamed SCH.
Since it is a bug in KiCad I filed a bug report with them.
Andy
Setting aside the possibility I screwed up I change only nets which have a reference designation. So I change a net with C6-Pad1 but not “DMA_ADDRESS_0”
Have you tired the software yet?
That is good news! Oddly enough I don’t think I got the email though. I checked my spam box etc.
With respect to the file problem, how I described it was how I created it.
I think (?) now it handles paths properly but I’ll make a path like you describe and see if it does.
I’d agree it is less common, but it is not uncommon, so should be covered.
Can you expand on this “change only nets which have a reference designation” ?
eeschema generates using the rules LowestSortedRefDes+"-Pad"+PadName, however, PCB side can get updates from other sources, and the master design may have imported from Eagle, Altium or others.
It could pay to check the hidden name rules for those packages ?
From memory some use “NN”+number, and some use “$$$” etc
The function of the program is to re name PCB component reference designations and back annotate that to the schematics. If schematics are not available because things were imported from other sources/net lists then they are not updated plain and simple.
Unless there is a reason to parse net names I am not going to expand the scope of the software unless I know it is widely used and there are problems with what it does.
I could have simply kept the development to myself otherwise.