I'm not sure about the proposed approach to hierarchy support by the db changes
- add field course_sections.parent (default 0) to allow sections hierarchy
- add field course_sections.visibleold to store original visibility when one of the parent sections is hidden
Given that in most cases we do not expect thousands or even hundreds of sections in a course it may be simpler to maintain a delimited list of sectionid-depth pairs in their order (the order is already there in the good old section field; please do rename to order or sortorder or similar).
0 56, 0 34, 1 57, 1 58, 0 35, 1 89, 2 111
which translates to the hierarchy
With such a list it should be fairly easy to handle moving/adding/deleting sections, to generate the navigation tree, to manage visibility and availability and most importantly to adjust in restore. That's how I implemented it in my (obsolete, thanks to your work on this important enhancement ) course format and it seemed to work reasonably well.
Of course, if the course manager doesn't set a hierarchy the field that holds the list remains empty and navigation is generated by the simpe order.