Something I really only understood recently:

The books I have about Sage say it uses nominal codes that can be up to 8 digits long, but they don't explain how it works.

Sage uses 8 character nominal codes.  Normally you only use 4 digit (characters).  Sage pads the right hand end of the nominal code with spaces to make it 8 characters long (a hangover from Cobol days of programming?).

As the nominal code is stored as a string and not a number, all sorting and range checking is done left to right.  Thus if you use more than 4 characters, Sage will use the left hand end to see where it fits in the CoA.

So what you can do is extend your 7001 to 7050 codes to the right and Sage will still consider them to be in the 7001 to 7050 range.

eg 700201, 700202, 700203, ... are all in the range 7001 to 7050 (in fact they are in the range 7002 to 7002!).

Sage does a string comparison from the left hand end of the nominal code, character by character:

Thus 700201 comes after 7001 as 7002 (it doesn't need the '01' part) is greater than" 7001, but before 7050 as 700 (it doesn't need the '201' part)  is less than 705 (it doesn't need the final '0' of 7050).

Similarly for the 7051 to 7100 range.

Seeing as the Customer ID is a string of 8 characters, they could convert it to an internal string of a number 00000000 to 99999999¹, and then all they'd need to do is add an extra field with the user visible code which would be indexed to the internal code and wherever there is a user input of that field, indirect it though the index.  Simples!

¹They could use a 64 bit number to store in the 8 characters (or 128 bit if they're using 16 bit [unicode] characters), but that'd require more type conversion work.

Excellent idea. The account ref must still be unique but the actual key field is an auto increase integer which is always hidden. This would allow the account ref to be changed because the key field is stored with the transactions and addresses instead. Of course there is no way Sage would countenance such a huge change to the database' I would certainly vote for this amendment

"Meaningful codes": Ah, you mean like starting the code with the first letter of their name followed by lots of numbers; then they get married and go from Smith to Jones...

We may as well just use a totally increasing numerical number¹, just like MS Access's Auto-fill-in-unique-incrementing-integers for Key fields²...

¹and keep a handy name to number list external to Sage, so that when a name changes we can update the list and the data can still be found.

²or perhaps Sage should've (like I did back in the early 1990s, in a simple stock control system for a friend (vastly improving the one another friend had written), used a field hidden from the user) to provide a unique reference for each set of data that could be used to link that data, and then use a User_Code-to-unique-key index list to access it (lust like Unix's inodes, holding the actual file data, are accessed from links in directories...).  After all, linking payments to invoices is done exactly this way using a unique incrementing integer.

Again I can recommend the Adept tool to change Customer and Supplier codes from personal experience. It is worth keeping up the annual maintenance as it probably needs a review of codes every year. Of course the theory is that you should not create meaningful codes for the reasons cited, but we all do it!