Not sure why you have unconnected track in the PCB? If the track is unconnected, does that not mean that the net in the schematic is unconnected too? In which case isn't that just a Not Connected pin on a device? If tracks and therefore nets are unconnected then putting the Not Connect "X" symbol on the unconnected pins in the schematic should fix this.

@andyfierman Andy, I don't understand why you think I have unconnected tracks. There are none. The request I made for a feature change is best explained further by an example, which also illustrates the DRC issue that may be linked to it. I have two tracks running between two connectors. The square pads at the top are Arduino connections. The left most is A0, and numbering continues in sequence from left to right. The connector below (P54) was connected to A0 and A1. However when laying out the board I found that connections to A1 and A2 would need to cross elsewhere on the board. This was resolved by swapping their functions, and all the connections to them in the main body of the board. I therefore amended the schematic so that all connections that had previously gone to A1 now go to A2 and those that used to go to A2 now go to A1. I ran "Update PCB" which as expected changed the connections, and incidentally "Replaced" P54. Not stricktly necessary by hey.  Following the update, hovering over the pads on P54 showed them on nets A0 and A2 - correct. The square pads stay as they are on nets A0 A1, and A2 - also correct. However the tracks retain net numbers A0 and A1 - incorrect, the upper track shows it is on net A1. At the square connector I moved it from A1 to A2 as in the picture above, and DRC errors appear because the track is on net A1 still. I manually change its net in the right hand pane to A2, so the circuit is now correct. This action would not be necessary if the "Update PCB" function updated the net assignment of the track as well and that is my suggested change. True it would still need to be moved from square pad A1 to square pad A2, but that would then clear any errors. Moving on the the consequences of the track's net NOT changing in step with the update, a DRC error (the cross in the screen shot above) shows Track to Track A1 to A2. But what was the A1 track has been moved and reassigned to net A2 so what's coing on? Deleting the track (a ratline appears between square pad A2 and the upper pad on P54 - correct!) and redrawing it has no effect upon the DRC. In fact, as the track is being drawn, any excursion into grid squares through which the old A1 track passed causes the DRC cross to appear, and A1 to A2 error to be flagged in the design manager. In the end the final solution to the problem of the "Phantom A1 track" was to delete both tracks A0 and A2 and plug P54, run "Update PCB" again, position the "new" p54, and draw its tracks. From all this I deduce that the Phanton track/pad issue is a function of tracks not taking up new net assingnments when Update PCB is run, and even when the track is reassignd in the right hand pane to its new net, the PCB layout "remembers" where it use to be and behaves as if it is still there. Saving the updated PCB had no effect upon the error, so it's not a conflict between server and local versions of the PCB layout. The solution is either to do as I suggest and update track net assignments as well as pads and components, (the ratlines no where to go) Or Publish guidance that when schematic changes are made and are to be incorporated into an existing laid out PCB, all the affected tracks and components need to be deleted from the PCB before the update is performed. I haven't tested this, but it seems a logical fix based upon my experience of the Phanton pad/track DRC and subsequent actions that cleared the errors.

My apologies: I misread "However any _connected_ tracks retain their pre-update assignments..." in your post!

Hi Yes, It is a known issue, we are looking for a good method to solve this problem. it will be fixed in the future, at now, we develop others features which we thought are more important. Thanks

@UserSupport Thanks for the info. Quite understand, there is a work around which, now I know the issue, I'll be happy to continue using until it's fixed. I got my first boards back and will start testing soon. Well done EasyEDA.