I was feeling generous, and new features aren't going to be considered any time soon, so here's a block that does what you want.

For it to just go horizontally across parents of the same parent category:
[block multi_level="0"]wiki_nav[/block]

For it to do full tree traversal:
[block multi_level="1"]wiki_nav[/block]

Or you can put it in the WIKI_PAGE_SCREEN.tpl template like:
{$BLOCK,block=wiki_nav,multi_level=1}

Full tree traversal is less efficient as it has to load the whole tree, but I did cache the tree so it shouldn't be too bad. That's why there's an upon_query hook, to flush out the cached tree if the Wiki+ tree is changed.

The block looks at the current ID in the URL to see where the user is currently at. So it only is going to work when used directly within Wiki+. Not that you'd want to place it outside of Wiki+.

You are absolutely awesome Chris. Do you have a "buy me a beer" function yet? I am glad to see it as a block, TBH. That makes it all the more versitile IMO. I of course just went and put it in the TPL, dressed it up in a div so I could center it.

It works, of course. The odd thing is the back and forward seem to be going based on page name in alphabetical order, instead of ID #, despite looking at your php code and I swear you have it wrote to go by ID #. No biggie though, it still works for what I want it to do. Maybe I can brush off an old php book and learn a little if it bothers me too much. It is at least keeping the pages in their categories.

Thanks again Chris, you rock.

Here's my Patreon if you like:
https://www.patreon.com/composr

It's ordering by the the_order field in the wiki_children table.
I am wondering if somehow that field became defunct intentionally, or if I forgot - because I can't see it being used in the code.

I'll take a look tomorrow.

Ok, so it's not meant to be ID order, it's meant to be the the_order field, which is different from any IDs.

And it's not, because of a bug in the sitemap code I just found, hot-fix in this issue:
https://compo.sr/tracker/view.php?id=4546

The block code did use the_order, but that was only actually in effect if multi_level=0.

Oh and the block cache needs emptying after applying that hotfix.

It works beautifully sir. Thank you so much!

I made a Composr-wide implementation of next/previous for a client, and have a patch. I haven't compared to this issue, but there is a lot of similarity. I've tagged this issue as v12, although I'm more thinking about the patch I made for the client than what I posted here as I like the idea of a consistent out-of-the-box Composr-wide solution that also supports mobile swiping (#2076).

EDIT: Patch is now outdated, would need refreshing.

Just to update this no longer works in Composr v11