Does nsupdate reformat reverse zone files

Question

When I run nsupdate to add PTR record "update add 1.1.10.10.in-addr.arpa. 86400 PTR test.example.com" , the 10.10.in-addr.arpa reverse zone prints that record as below which is what I would expect. 10.10.in-addr.arpa is a /16 zone so I have 2 octets in the host section (1.1).

    $ORIGIN .
    $TTL 3600   ; 1 hour
    10.10.in-addr.arpa  IN SOA  ns1.example.com. admin.example.com. (
                3          ; serial
                3600       ; refresh (1 hour)
                600        ; retry (10 minutes)
                1209600    ; expire (2 weeks)
                )
            NS  ns1.example.com.
    $ORIGIN 10.10.in-addr.arpa.
    1.1         PTR test.example.com.

However, if I run nsupdate with an additional PTR record, "update add 2.1.10.10.in-addr.arpa. 86400 PTR test2.example.com" ,then the 10.10.in-addr.arpa zone file is reformatted to a /24 zone with only 1 octet in the host section. Like this:

    $ORIGIN .
    $TTL 3600   ; 1 hour
    10.10.in-addr.arpa  IN SOA  ns1.example.com. admin.example.com. (
                4          ; serial
                3600       ; refresh (1 hour)
                600        ; retry (10 minutes)
                1209600    ; expire (2 weeks)
                3600       ; minimum (1 hour)
                )
            NS  ns1.example.com.
    $ORIGIN 1.10.10.in-addr.arpa.
    1           PTR test.example.com.
    2           PTR test2.example.com.

If I manually add the same PTR records to the zone files then the 10.10.in-addr.arpa reverse zone remains as expected with 2 octets in the host section. So the issue is related to nsupdate and how it formats the zone files

What I would like to know is: Is this nsupdate formatting of reverse zone files expected? If yes, is there a way to manipulate the entry so that it maintains the format based on the the number of octets in the reverse zone as shown in the test.example.com example.