Ano,
You're misinformed and incorrect here.
I've had to dissect these things and their operation when a customer wanted to propose a similar solution with multiple panels, both when they first came to market and during more recent times. I realize your understanding is based off what you observed with your install, but it's not how the unit and NA function. 20 years in the trade and building private listed CS with all formats of communication methods and routes here. No conjecture or reading into how the "white box" functions with the alarm panel, all facts here.
The ABN will provide voltage whether or not there is a viable connection to the CS, sure it'll die if there's no network connection, but what happens if there are other network issues (as is typically common). In your case, if you're getting a response in 40 seconds that there's no issue, fantastic, but that's not what our testing and our end user's testing verified. This is part of the issue when people install a cell dialer on the same system that uses VOIP or "digital phone service". Voltage, irregardless of a viable connection. That in itself will render any line cut monitoring or failover impossible. A big blue alarm co paid out a 9 digit settlement with that being part of the evidence presented against them (system design faults). In your experience, the only item that NA is seeing is whether or not they get essentially a ping back.
The panel does not know it's connected to a CS. Physically impossible. The ABN is dialer capture, remember? All it needs to do is emulate a receiver handshake and kissoff and the panel is happy. That's the nature of the beast. You provide that and the panel will always remain happy, even if the signal isn't sent. You'll never get a FTC on the panel, which is fact. This is also sometimes a concern with dialer capture style cellular communicators. If your panel sends a non-standard or one off RC, it will not be retransmitted or it will be sent as essentially garbage to the CS receiver downstream. This is why dealers have to pay specific attention to what dialer format is being used and the supported RC's. CID is not a guaranteed fix (configurable zones and RC's for the same is one big reason, same with extended system data).
This is also the reason why NA does not require the end user (or whoever is installing the ABN) on an already functional panel to reconfigure the dialer, report codes, primary or secondary phone lines etc. The ABN is not bidirectional passthru communications. Physically impossible, otherwise it'd be an ATA, just like VOIP. This isn't unique to NA, as cellular dial capture units and even what is referred to in the business as "panel savers" do this. Facilitates a takeover on a locked out panel.
And finally, not every panel out there will supervise the phone line. If they do, it's great, but if not, or more commonly, a nuisance delay before the line fault is discovered, then neither system is going to notify the end user of an issue. That means the panel can be physically disconnected from the ABN and NA and the end user will never know or will be delayed until the nuisance delay expires or the connection (usually intermittents) clear and restore.
If you'd like to discuss CS construction, operation and communications routing and formats, feel free to call me. I'm out there. But how NA and their ABN work are not how you described. Part of the reason why it is not a UL listed communications method.