I think I see what you mean. You want to keep the structure of as many 
backends as possible updated, to make it easy to switch from one to 
another.
From my point of view, any structure check/migration could be 
performed when the driver is changed or the data migrated via the 
scripts you provide, but in this case, since the tables are so 
similar, I can understand how it's easier to maintain that way, 
instead of modifying the configuration scripts.

Yes, since some installations may have explicitly kept using the 
"legacy" share driver.
If you run NG for some period of time and then switch back to non-NG, 
yes, then any new shares or perms that were changed since the switch 
to NG would be lost.  The idea of having both drivers isn't to allow 
admins to switch back and forth at will, but rather to give a choice 
in drivers. Originally, IIRC, some fringe cases were showing better 
performance with the original driver (though this has probably changed 
since then), so we continued to provide, and maintain both drivers.

This is no different than supporting different database backends, or 
address book backends, or authentication backends etc... Just because 
we provide different drivers to switch between doesn't mean that data 
should be somehow automagically preserved when switching.

That being said, we DO offer a script that can convert between non-ng 
and ng shares at will. We just don't offer the backwards conversion at 
will since the idea is to move everyone towards the new driver anyway.

On the one hand, I understand your position. It's never been removed, 
so you keep the schema updated, but if data is lost when switching 
between NG and non-NG (no data is migrated between tables), then maybe 
it would be best to update the schemas of what the installation is 
using and to use scripts to migrate from one backend to another?

(I haven't checked if data is copied over when switching backend)

You shouldn't perform operations like this outside of migrations.
They are used if the installation is not using the "next generation" 
share driver. Both are still maintained.

We've migrated properly in the past, but then switched to using 
sharesng and removed the old shares tables which only contained 
duplicated data.

Where are the old tables used? They were never kept in sync with the new ones

If you don't have that table, you didn't migrate properly in the past. 
You must migrate from an up-to-date Horde 3 version, as clearly 
documented in the upgrade instructions.

Here is the message I get when trying to update the database schemas
SQLSTATE[42S02]: Base table or view not found: 1146 Table 
'webmail.turba_shares' doesn't exist

In our database, all the "shares" tables are named sharesng. It 
probably happened when converting the backend from datatree to SQL.