I see 7 types all called Error within the same codebase. Is this acceptable?
My instinct says that having types with the same name in different domain contexts is OK, but it makes ambiguities increasingly likely when dealing with the "mother solution".
If they are in different namespaces then this is OK - this is what namespaces are for. If the namespaces deal with different parts of the system why should they be coupled together to use shared Error types. If the namespaces are coupled for other reasons then you might be able to argue that they could share the same Error type to share code.
The idea of namespaces is to allow this, and in many situations, it is ok. On the other hand, it makes some things harder
global search for all places of a specific type may suffer from getting too many results
moving one of those types to a more top-level component for wider re-use may be harder.
At all, IMHO it is not a all-or-nothing decision. Every time you choose a name for a type already there in another namespace, you should reconsider for a second or two if there may be not a better name, avoiding this.
Identically named types are perfectly legitimate as far as the compiler is concerned. However, although the compiler will happily distinguish between the types provided the references and using statements are unambiguous, this does not mean that it is unambiguous for a programmer reading the code.
Error sounds like it could be an equivalent of the Exception class which is the base of the CLR exception type hierarchy; this seems like a good model for describing errors. Perhaps you could pull out common behaviour between your error classes into a single base class called Error, and then inherit from this to produce more concise or project-specific subclasses.