ZeroTier Central managed routes with a leading zero octet aren't being reflected on the client

I've set up a variety of Managed Routes within ZeroTier Central for testing, including an entry for default route (0.0.0.0/0, which I believe gets translated internally to 0.0.0.0/1 and 128.0.0.0/1 on the client).

The route entries that have a nonzero leading octet (like 10.42.0.0/16, 242.0.0.0/8) are successfully being propagated to the client (Linux Debian and Ubuntu), in that the routing table quickly shows those very entries just like they are provided in the ZeroTier UI.

However, any entry that begins with a leading zero octet (such as 0.0.0.0/3, 0.1.2.0/24, 0.1.0.0/16) is not being propagated in any way to the client.

A use case I have is to let a client connect to two ZeroTier networks, each of which provide outbound internet connectivity. When the "primary" one is connected (as I'd like it to be at all times), this shows in the routing table as 0.0.0.0/1 and 128.0.0.0/1. But when the "secondary" network is also enabled and connected, then routing entries like 0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, and 192.0.0.0/2 are meant to override the first one in the routing table. This leaves the primary one as always valid and an acceptable fallback. But the secondary one carries the actual traffic when it is enabled.

It seems that what's in the way of this working is some kind of automated filtering on route entries that begin with a zero octet.

Start by reproducing the managed-route behavior on the Linux Debian or Ubuntu client using routes with leading-zero octets, then trace how ZeroTier Central route entries are propagated and filtered. Done means routes such as 0.0.0.0/3 and 0.1.2.0/24 appear on the client routing table while the existing default-route behavior remains intact.