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)

No, they each have a separate power of two in their canonical floating-hex (%a) representation

Yes, that was careless thinking ("thoughtless thinking" might be a better term) on my part.

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

Agreed.
However, there were a couple of things in your last post that I couldn't quite follow.
I'll mention them here, and you can respond if you like - but I think we both understand what we're doing, so please feel free to not respond at all. (I think you've probably already put more effort into this thread than you would have been expecting.)

IIUC, in respect to the value 0.3, you wrote "whereas the ULP is 3.5e-18", yet I believe it's actually 5.551115123125783e-17.

You also wrote "I have to subtract 23 ULP from the canonical 1.03 representation before it doesn't round up to 1.03 displayed".
I take it that was in relation to the difference between 1.03000000000000003e+00 and 1.02999999999999980e+00 .
Firstly, I think you should have been looking at the "%.16e" or "%.17g" (not "%.17e") formatting of the values.
Secondly, by my way of thinking, the difference between 0x1.07ae147ae147bp+0 and 0x1.07ae147ae147ap+0 is 1 ULP, irrespective of what the chosen decimal formatting shows.

Anyway, thanks for the time you've taken in clarifying and correcting.

Cheers,
Rob