@WQing I guess I’d be one of the naysayers of using namespaces to implement hierarchies, even strict ones (I just outlined some reasons here).
Your post made me realize that this is not only because of flexibility, but because we need both concepts, namespaces, and hierarchies, and we should not mix them up.
I feel that namespaces are a very import and much needed concept, and that they should be reserved for actual namespaces (i.e. disambiguating the same names in different contexts).
Your example is actually an excellent use case for using namespaces (in the Logseq sense) as proper namespaces (in the computer science sense), for keeping things with the same names apart, but not for building hierarchies.
A taxonomy is
The classification and naming of organisms in an ordered system that is intended to indicate natural relationships, especially evolutionary relationships.
A tag like “subproject 1” wouldn’t be part of any properly designed taxonomy. (like “car” in “vehicles”, “cat” in “animals”). On the other hand, there would still be many “subproject 1” around, this is why they need to be put into a namespace, such as “Project 1”/“subproject 1” to distinguish them.
One of the main criticisms of using namespaces to implement hierarchies (in the sense of taxonomies) is that there is no way to centrally edit the hierarchy. If you’ve tagged a page “cat”, once there are a lot of pages, you might want to organize them into a taxonomy without editing each tagged block individually.
One the other hand, in the “subproject 1” case, “subproject 1” isn’t a meaningful name by itself, like “cat” is. It makes sense to centrally sort all of the “cat” blocks under “mammals”, but it doesn’t make sense to centrally reclassify all “subproject 1” tags, because they all live under different projects. A category “mammals/cats” makes sense, a category “All projects/first subprojects” doesn’t.
If someone made the mistake of individually tagging his pages separately with “Project 1”, “Project 2” and “subproject 1”, the tag “subproject 1” by itself is ambiguous. Many projects have a “subproject 1”, and there is no way to further classify them.
That’s why in your case, the use of namespaces is correct, even a naysayer like myself can absolutely agree with this use.
All of these projects should be tagged, as you suggested, “Project 1/subproject 1”.
This is the proper use of namespaces (to keep the same names used in different contexts apart), but not a good example of a hierarchy (in the taxonomic sense, to classify things in a system).
Ultimately, we’ll need a way to specify relations between tags, and these tags could very well be disambiguated by the use of namespaces.
tl;dr namespaces are good for keeping identical names apart, they are not good for taxonomies.