If these considerations are relevant to the post that started this thread

As far as I can tell, they are tangential. My reasoning is expanded in the rest of my reply.

The doubles 0.5, 0.3, and 0.1 all have ULPs of the same value (2 ** -53)

No, they each have a separate power of two in their canonical floating-hex (%a) representation, and since the ULP is just the value of the lowest fractional bit, they each have a separate ULP:

perl -MData::IEEE754::Tools=ulp -le "printf qq{ULP(%s = %22.13a) = %.1
+7e = %22.13a\n}, $_, $_, ulp($_), ulp($_) for 0.5,0.3,0.1"
ULP(0.5 =   0x1.0000000000000p-1) = 1.11022302462515654e-16 =  0x1.000
+0000000000p-53
ULP(0.3 =   0x1.3333333333333p-2) = 5.55111512312578270e-17 =  0x1.000
+0000000000p-54
ULP(0.1 =   0x1.999999999999ap-4) = 1.38777878078144568e-17 =  0x1.000
+0000000000p-56
[download]

yet they all differ from their respective rational representations (5/10, 3/10, 1/10) by different amounts.

Yes, the canonical double-float representation differs from the exact rational representation by different amounts, but each is bounded by their ULP.

It seems to me that the (details of the) behaviour reported by the OP has more to do with the size of the rounding error, than with the value of the ULP.

I agree with that assessment. When the machine epsilon was brought into the conversation, I was trying (poorly, perhaps) to explain why I thought the epsilon wasn't relevant -- or at least, not the right fix --, and I used the ULP to show that even the stored error changes with magnitude, and applying the epsilon as an absolute value when the values being used were changing their power-of-two-magnitude was inaccurate.

Going back to the example of 0.03:

perl -MData::IEEE754::Tools=ulp -le "printf qq(%.17e = %22.13a => %s\n
+), $_, $_, $_ for 0.03, 2.99999999999999989e-02, 2.99999999999999503e
+-02, 2.99999999999999468e-02, ulp(0.03)"
2.99999999999999989e-02 =   0x1.eb851eb851eb8p-6 => 0.03
2.99999999999999989e-02 =   0x1.eb851eb851eb8p-6 => 0.03
2.99999999999999503e-02 =   0x1.eb851eb851eaap-6 => 0.03
2.99999999999999468e-02 =   0x1.eb851eb851ea9p-6 => 0.0299999999999999
3.46944695195361419e-18 =  0x1.0000000000000p-58 => 3.46944695195361e-
+18
[download]

So even if 1ULP was the same as epsilon, which is only true for 1.0 up-to-but-not-including 2.0, the rounding is different. For example, I have to subtract 23 ULP from the canonical 1.03 representation before it doesn't round up to 1.03 displayed:

perl -MData::IEEE754::Tools=ulp -le "printf qq(%.17e = %22.13a => %s\n
+), $_, $_, $_ for ulp(1.03), map 1.03-$_*ulp(1.03), 0..5,22,23"
2.22044604925031308e-16 =  0x1.0000000000000p-52 => 2.22044604925031e-
+16
1.03000000000000003e+00 =   0x1.07ae147ae147bp+0 => 1.03
1.02999999999999980e+00 =   0x1.07ae147ae147ap+0 => 1.03
1.02999999999999958e+00 =   0x1.07ae147ae1479p+0 => 1.03
1.02999999999999936e+00 =   0x1.07ae147ae1478p+0 => 1.03
1.02999999999999914e+00 =   0x1.07ae147ae1477p+0 => 1.03
1.02999999999999892e+00 =   0x1.07ae147ae1476p+0 => 1.03
1.02999999999999514e+00 =   0x1.07ae147ae1465p+0 => 1.03
1.02999999999999492e+00 =   0x1.07ae147ae1464p+0 => 1.02999999999999
[download]

So yes, we've probably gone far enough on this tangent.

(NB: using windows cmd.exe-style command-line quoting throughout)