Yes, we don't want fully qualified class names. They are fragile (refactoring breaks existing configs). They are verbose, which makes them user-unfriendly. And they often don't convey a lot of information that would help a user understand the configuration.
FQCNs if absolutely necessary are ok for extension points (where users plug in some class that implements an extension API). But then use a different attribute (and perhaps a different element) where the user declares the class. For standard configurations using our classes, use a different element, and/or a different attribute with aliases as the value. Or, if we only ship one implementation of something, don't mention it at all in the config.
For example, the domain configuration for HornetQ involves configuring connectors, so there are options like:
<netty-connector name="external"><param name="x" value="y"/></netty-connector>
<in-vm-connector name="in-vm"><param name="x" value="y"/></in-vm-connector>
<connector name="custom"><factory-class>com.xyz.XyzConnectorFactory</factory-class><param name="x" value="y"/></connector>
The 3rd variant supports arbitrary extensions, but 99% of users won't use it; they'll use one or both of the first two variants.
Note the 2nd variant is much better than the first; the first leaks implementation details (use of netty).