First of all, thanks for your interest and for your suggestions.
Let's get through this:
(1) Y-switches: Since all other switches have speed restrictions on the diverging path, but not on the straight one, one would have to apply the speed restriction on both paths, an impact to consider, which has made the introduction of them a low priority. Not impossible, but requires changes in route handling.
(2) Hard interlock of switches: As you mentioned, CTC features "protect switches", which is part of routing. Also, you don't really have many situations which requires to throw switches manually - essentially if you want to prepare a path for a train to be moved via passing a red signal. In real life, I don't think switches are linked such that only one motor operates more than one (you may have one button or knob that activates all motors involved). Even in the mechanical days, you would have to apply more muscle power to throw 2 switches at once with just one handle, although I know examples where derail devices and switches are operated together. So that's why we don't link them together, unlike TDP (where you don't have a choice and can get undesired results). So that would be a very low priority.
(3) Default states of switches: this is worth considering. We have already certain default values stored in the config file (per territory). So that can be expanded. Of course, one need to solve conflicts from the config file vs. saved game state files.
(4a) Self restore of switches: I believe that in real life that is controlled by the software controlling switches and signals from the control tower. I know from Germany, that this is done sometimes - and has led to an accident when a route was manually released and switches turned to default position while the train was still out there.
(4b) Spring-loaded switches: It is currently under consideration to enhance switch features such as spring-loaded switches, switches not to be controlled by the dispatcher, needs to be thrown by the train crew (locking controlled by the dispatcher). Technically, within CTC, a switch needs to be turned away from the default if a route is laid in requiring it (it is also route-locked), so after the train is through a switch can be turned back after a time out (also good for point 4a).
(5) Overlap: Not sure I understand the point about switches - it is already part of the protection scheme. Signals cannot be cleared if a route cannot be laid in, so not sure if it would add anything. Track sections is worth considering.
(6) Linking: I know, there must be a better way doing this. Will think about it.
(7) Group move: Within the detailed block window you can select more than one track element (hold shift key down while clicking on track elements to toggle them on or off) and you can move them all at once. When moving from the pool, the positions of the moved elements may be adjusted as to not conflict any elements already on the scene.
(8 ) Texts: Makes sense.