It is definitely a good rule of thumb that if you've got a common prefix on a bunch of classes, then they probably deserve to go in their own namespace. To deal with the problem then, when you need to use similarly named classes from two namespaces:

1. Alias the namespaces, though I'd make it short and to the point, any natural abbreviation, maybe even just 1 letter:

   using Sm = Smurf; using W = Wartmonger;

Then always prefix wherever used and name instances appropriately:

Sm::Configuration smConf; 
W::Configuration wConf;

2. Alias the class, as suggested in other answer.

   using SmConf = Smurf.Configuration;

3. Any library you have control over, consider not using the term 'Configuration'. Use thesaurus: e.g. 'Settings', 'Model', 'Parameters'. Might be more meaningful to the context anyway: E.g. if Smurf was some sort of numerical analysis module you'd written perhaps 'Parameters' would be better for its configuration. Use the particular vocabulary associated with a module's context to your advantage to come up with unique names that hold uniqueness even when mixed into other namespaces.

4. Refactor code so that you don't have to mix the use of configuration from two different places. Details of that are up to you.

5. Combine the two configurations into one before you pass it into your class. Use a combined conf class to represent:

   struct Conf { SmurfConfiguration smurf; WartmongerConfiguation wart; }

The short member variable names are now kind of achieving the same thing as aliasing the class/namespace.

It is definitely a good rule of thumb that if you've got a common prefix on a bunch of classes, then they probably deserve to go in their own namespace. To deal with the problem then, when you need to use similarly named classes from two namespaces:

1. Alias the namespaces, though I'd make it short and to the point, any natural abbreviation, maybe even just 1 letter:

   using Sm = Smurf; using W = Wartmonger;

Then always prefix wherever used and name instances appropriately:

Sm::Configuration smConf; 
W::Configuration wConf;

2. Alias the class, as suggested in other answer.

   using SmConf = Smurf.Configuration;

3. Any library you have control over, consider not using the term 'Configuration'. Use thesaurus: e.g. 'Settings', 'Model', 'Parameters'. Might be more meaningful to the context anyway: E.g. if Smurf was some sort of numerical analysis module you'd written perhaps 'Parameters' would be better for its configuration. Use the particular vocabulary associated with a module's context to your advantage to come up with unique names that hold uniqueness even when mixed into other namespaces. I feel this might be kind of an answer to OP question 2.

4. Refactor code so that you don't have to mix the use of configuration from two different places. Details of that are up to you.

5. Combine the two configurations into one before you pass it into your class. Use a combined conf class to represent:

   struct Conf { SmurfConfiguration smurf; WartmongerConfiguation wart; }

The short member variable names are now kind of achieving the same thing as aliasing the class/namespace.