I knew you can put enums inside a class (like pretty much everything) but I didn't realize you can then use the class name as outside access to that enum if it's public. What this means in my case I can remove some namespaces I've created for enums. In a large project any name that is introduced increases the complexity, so using class enums is in many cases a better option, because usually enums are used inside the class and sometimes outside. As added bonus the enum will be "open" (as with namespaces) inside the class, but always closed outside (requires the access name).
There is also something called enum class, not to confuse with class enum, but it seems to be too advanced to even look at it.
Namespaces are weird. They were designed for modular style I guess, but in reality they are used to replace old school "hungarian" notation where some letter or combination is used in front of the name, like iDagger or itmDagger or itemDagger for items, and replaced with item namespace with outside access style item::Dagger. But sometimes even I'm using namespaces for modules and they are really useful to avoid name clashing problems which eventually will become reality when the project is getting bigger.
Like I said before I've backtracked too modular style, because modules should be "natural" I guess, containing stuff that's actually related and possibly even working together as a.. well, module. I think in OOP style the most important thing is a good low level or datatype class foundation and then the actual code is built using those classes, rather than writing too much "low level" code everywhere. That way the source code becomes easier to maintain, which is not the case with Kaduria.