If you figure out more ways, take it on the PR above.
Think about it this way: if your PR changed the results, it was because it followed a different code path in .GetPage, no longer using the new “relative” file-name code. Here’s what your suggestion does to my site (working under 0.64, working except for no results from .GetPage under 0.65):
% ./hugo-0.65.2
...
Error: Error building site: failed to render pages: render of "taxonomy" failed: "/Users/jgreely/dotclue/themes/mt2-theme/layouts/taxonomy/comment.html:7:43": execute of template failed: template: taxonomy/comment.html:7:43: executing "taxonomy/comment.html" at <site.GetPage>: error calling GetPage: page reference "/000038" is ambiguous
% find content -name "000038*" -print
content/post/0000/000038.md
content/_comment/000038
content/.hg/store/data/post/000038.md.i
content/.hg/store/data/post/0000/000038.md.i
content/.hg/store/data/__comment/000038
If your “fix” was still doing file-name lookups, it wouldn’t have bitched about an ambiguous reference, because there is only one file named 000038.md; there’s a sub-directory (not a nested section!) with the same name, which I presume is what makes it “ambiguous”, but no conflicting file.
(and, just in case, yes, I do have ignoreFiles = [ "content/.hg" ] in my config)
-j
So I think this finally boils down to the fact that the two files above gives and “ambiguous error” in site.GetPage, which may be a change/bug. If you can articulate that part as a new GitHub issue, I will have a look at it.
Let’s continue this on GitHub. I’m plenty tired of this thread.