except that, in place of # /etc/init.d/network restart, I rebooted the router (with # reboot).
The result was that the router had apparently lost its DHCP function. It was not handing out I.P. addresses in either the old or the new subnet. (The computers had self-supplied I.P. addresses, i.e. those which they seem to use when not connected to any router.) (Yes I turned the computer's network connectors off and on and turned the machine itself off and on.)
Note that the router itself had received the new internal I.P. just fine. A computer to which I entered a manual IP in the new subnet could get to the router no problem. It's just that there was no DHCP from the router.
After a factory reset, I used the quoted steps exactly including the restart line, and everything turned out fine (router doing DHCP in the new subnet).
Is it expected outcome that a reboot would not accomplish # /etc/init.d/network restart? Or have I run into something quirky?
a restart of the device will restart all services, so it should not have a different effect than restarting just a single service.
I think you may have made some syntax errors the first time.
afaik if you make syntax errors in UCI config files it can break the system because it stops reading configuration of other services too. If you break the config that is read before DHCP config, the DHCP config will not be read.
See the Corrupted Configs paragraph at the end of this article, and its link to the uci config validation script you can install and run to make sure you did not write syntax errors that screw up UCI system.
Several more trials confirm that rebooting my router restarts /etc/init.d/network.
Rebooting is rather better in that the computer loses the connection for a while and, on being connected again, automatically receives an IP address in the new range (as if the LAN cable had been plugged out and in).
After a # /etc/init.d/network restart I have to turn off and on the network connector manually.