The following is fairly typical...
third-party library
release
obj
debug
obj
include
src
sublib 1
sublib 2
mylibrary
release
obj
debug
obj
include
src
sublib 1
sublib 2
myapp
release
obj
debug
obj
subapp 1
subapp 2
mylittleapp
release
obj
debug
obj
Basically, subfolders for subprojects is common for larger projects, but mostly a particular project has folders for src, include etc. A folder for each build configuration is common, and keeping the obj files and other intermediates in a subfolder of that is a good idea. It may be tempting to put subproject folders in obj folders, but usually that's unnecessary - the obj folders don't need to be well organised, so the only concern is a filename conflict, and the best fix for that is to have unique source filenames within (at least) each project.
The "include" folders should IMO only contain headers that will be #included by other projects - internal headers belong in the "src" folder.
Putting UI stuff in a separate folder isn't a bad idea, if it's big enough. I've seen UI stuff done as a separate static-linked top-level project, and I do mean app-specific here, not (e.g.) wxWidgets. Usually, though, that level of division is sub-project if it's worth separating at all. How you divide subprojects is more a matter of application-specific blocks in general, so it depends on whether UI stuff is best handled as a separate block or as separate chunks mixed in with task-specific logic.
Namespaces aren't the most used language feature, possibly because a lot of people use "using" so much they don't make much difference. A namespace for a main library project makes sense, but associating subfolders to namespaces 1:1 isn't something I've seen. I personally have a namespace that encompasses most of my library code, with a couple of sub-namespaces for things rarely used in general, but used a lot in a few places (e.g. a "bitwise" namespaces). The sub-namespaces are limited to single source/header pairs, so no need for subfolders. Most of the library-specific selection is done by including the right header - except that I usually include the lot through a main-project top-level header anyway.
Basically, namespaces are a way of avoiding naming conflicts. They don't necessarily associate with abstractions or functional blocks or anything. Within a particular project, you're probably better off just making sure the names don't conflict. As with the "std" namespace, it's fine to put a lot of stuff in one namespace.
As you say, though, this isn't a definitive answer - there are of course minor variations and quite different approaches.