There appears to be a somewhat-recently created bug in /usr/bin/sort.
I ran this same test last year on a -current /usr/bin/sort and
FWIR, it did not behave this way. This came up because we noticed
that Solaris 2.9 changed their sort behavior and broke our code
which depended on how numeric sorts behaved. At the time, NetBSD's
sort 'correctly' performed reverse/numeric field sorts but I don't
remember the actual timeframe in which I tested this.

sort-bug-test-file :
----
 1.000 1.000
       1.000
 1.000 1.000
       1.000
 0.000 1.000
       1.000
 1.000 1.000
 0.000 1.000
       1.000
----

Solaris 2.8 (correct):
$  /usr/bin/sort -t: -k1.7,1.12n -k1.1,1.6n sort-bug-test-file
       1.000
       1.000
       1.000
       1.000
 0.000 1.000
 0.000 1.000
 1.000 1.000
 1.000 1.000
 1.000 1.000

$  /usr/bin/sort -t: -k1.7,1.12nr -k1.1,1.6nr sort-bug-test-file
 1.000 1.000
 1.000 1.000
 1.000 1.000
 0.000 1.000
 0.000 1.000
       1.000
       1.000
       1.000
       1.000

Solaris 2.9 :
$  /usr/bin/sort -t: -k1.7,1.12n -k1.1,1.6n sort-bug-test-file
       1.000
       1.000
       1.000
       1.000
 0.000 1.000
 0.000 1.000
 1.000 1.000
 1.000 1.000
 1.000 1.000

$ /usr/bin/sort -t: -k1.7,1.12nr -k1.1,1.6nr sort-bug-test-file
 1.000 1.000
 1.000 1.000
 1.000 1.000
       1.000
       1.000
       1.000
       1.000
 0.000 1.000
 0.000 1.000

NetBSD 1.6ZI :
$ /usr/bin/sort -t: -k1.7,1.12n -k1.1,1.6n sort-bug-test-file
       1.000
       1.000
 0.000 1.000
       1.000
 0.000 1.000
       1.000
 1.000 1.000
 1.000 1.000
 1.000 1.000

$ /usr/bin/sort -t: -k1.7,1.12nr -k1.1,1.6nr sort-bug-test-file
       1.000
       1.000
 0.000 1.000
       1.000
 0.000 1.000
       1.000
 1.000 1.000
 1.000 1.000
 1.000 1.000

Sun says their change was a result of some (unknown) pressure to
comply (to what?). NetBSD's seems simply broken.