Modernize host server by IP routing functionality

I would like to see the older capability to route by IP address modernized and enhanced.

In i7.3 (and TRs for 7.1 and 7.2), new functionality was added to route host server jobs by the user name, managed entirely using SQL Stored Procedures. (Reference: http://www-01.ibm.com/support/docview.wss?uid=nas8N1021000) This appears to be much more admin-friendly than the way the IP-based rules are managed.

Documentation for the host server IP routing as it stands now: N1021000 Routing Connections to Subsystems Based On User ID, https://www-01.ibm.com/support/docview.wss?uid=nas8N1019587

First Requirement: Add procedures to manage and maintain entries for routing to host servers by IP via SQL.
Currently, there is no way to manage the host server IP routing outside of Navigator. This leaves no way to script the entries to apply them on multiple partitions - they all have to be entered manually. UX is very poor for this feature, with a very limited list view regardless of browser area, subnet masks displayed in CIDR notation on the list but entered and displayed in dotted notation on the edit screens. Being able to list (and sort and filter!) these entries via SQL would be very helpful.

Second Requirement: Change the rule definition to be consistently a combination of network address + subnet
Currently, these rules confusingly specify an "IP address" or "IP address range", both requiring a subnet mask, Common practice for IP configuration is to either specify absolute ranges, or to specify a network address and subnet, but not either/both. ADDTCPRTE for example takes a single address and subnet mask.

Third Requirement: Make the rules consistently apply using most-specific rule first
Document N1015862 Host Server Customization Requirements for TCP/IP Address and Subnet Mask, https://www-01.ibm.com/support/docview.wss?uid=nas8N1015862, explains the how the subnet masks work. At the bottom of this document, it indicates that "the order that the entries ad added to the list will also affect the outcome." The problem here is Navigator always displays the entries sorted by IP Address, with the "IP address" entries first, followed by the "IP address range" entries -- there is no way to see what order they were actually added in. I would suggest a better way to do this is to take the most-specific match. Example: For rule A = 192.168.1.0/24 and rule B = 192.168.1.32/30, the addresses 192.168.1.32 - 192.168.1.35 would use rule A, and addresses 192.168.1.0 - 192.168.1.31 or 192.168.1.36 - 192.168.1.255 would use rule B, regardless of what order they were added.

Fourth Requirement: Store this data in a reliable fashion
The notes in the "How it All Works" section of the N1021000 document state "user index objects are not particularly stable and have been known to be damaged by an IPL". This is not the level of confidence or reliability that I expect from IBM products.

Allow scripting IP address routing for host servers (especially QZDASOINIT) to deploy across multiple systems. Reduce training burden by removing ambiguity and confusing combinations of address ranges and subnets. Remove need to save user index object after every change. Remove need to restore user index object at every IPL.