It's a little bit of work up front, but if you define a custom type with separate overloads for each arithmetic operator/operand type combination (i.e. *(float), *(double), +(float), +(double), etc.) you should be able to offer a single namespace with constants that auto-promote (or demote) to the right type in expressions. That's also easily extensible to user-defined storage classes such as an extended precision float, and I think it's more maintainable since the using declaration (which is now untyped) can't get out of sync with the usage context. To prevent ambiguous overloads (in contexts where the constant itself is supplied as an argument to a polymorphic function, not in expressions), you can leave just one type (perhaps double) as implicitly castable-to, with explicit casts for the others.
A fundamental problem with proxies and things that try to rely on correct usage of conversion is that the conversion won't kick in when dealing with templates, as they do not matter when deducing template parameters. It's very easy to taint your types in such a way that a lot of machinery goes very very wrong.
Nod. There was some work on this I seem to remember after Paul's previous constant-lib review failed, but it never really fully worked well enough... John.