If you create wiki:foo it creates the file wiki/foo.txt on the backend.
If you then create wiki:foo:bar then it creates wiki/foo/bar.txt and the backend file structure is now:
wiki/
wiki/foo.txt
wiki/foo
wiki/foo/bar.txt
For our site this is the usual use case. A page is made but when more info is added subpages get created and the original page wiki:foo becomes a namespace as well as the original page.
Sometimes someone will create wiki:foo:bar when wiki:foo doesn't exist. If a user then goes to wiki:foo and edits it to create the page it actually creates wiki:foo:start and the backend file structure is now:
wiki/
wiki/foo
wiki/foo/bar.txt
wiki/foo/start.txt
To me this seems inconsistent - both wiki:foo and wiki:foo:start can act as the initial page for a namespace and which one is in place depends on the order pages are created in (basically whether or not the directory or txt file exists first on the backend).
This is especially annoying when (like my site) the main navigation paradigm is using the indexmenu plugin as the presentation is inconsistent. I know that the wiki way of doing things is creating links and having a fairly flat file structure but try telling that to a group you are weaning off a massive directory tree full of word documents.
The other issue is that it's possible to create both wiki/foo.txt as well as wiki/foo/start.txt - this causes wiki/foo.txt to be effectively hidden, you cannot get to it without URL manipulation. If navigation is primarily done using indexes then this is a problem.
This seems to be intended behaviour (
http://www.freelists.org/post/dokuwiki/globalstart-patch ) but I don't understand the reasoning for it. What is the purpose of the start.txt for subnamespaces? Wouldn't it be better to always create foo.txt alongside foo/ instead of the start.txt page underneath so that the backend file structure is consistent?