[un_pogaz]

Well, that such an "error" since V2 (I checked) seems to me aberrant.
We're talking about Calibre, it's monstrous. There must be a reason.

After a lot of thinking, I came to the conclusion that this "inconsistency" was there to detect the series indexes, like this:

is_float
    cc.label == 'size' or data['datatype'] == 'float' and cc.is_custom and cc.label != 'series_index'

is_series_index
    cc.label == 'series_index' or data['datatype'] == 'float' and not cc.is_custom and not cc.label == 'size')

this code allows to filter between "true" float (that alone) and the "series_index" float associated to a series.

And to get the name (with prefix of custom), we need to make something a little bigger

if self.is_custom or cc.is_float and cc.label not in ['size', 'series_index']:
    return '#' + self.label
else:
    return self.label

... or maybe, not. I'm looking at the FieldMetadata code, and the real detection of it's is a custom field is done on the 'key' of the dictionary it was in, not on the FieldMetadata object itself.
'key' created previously, in a different context with differents functions.
So if you ever iterate all the field on GUI.db.field_metadata but only process the value (like .values() ), poof, your lost the TRUE identifier of this is a custom.
...
Finally, if it's really a bug/blunder: No, don't fixe it.
Do like all dev:
It's not a bug, it's a feature *magic*.

Because otherwise we will not be able to detect if the field is a "true" float or a series_index, as I just did.
And I will modify my code to have a private bool that will remember that a custom custom, it will be easier.