RCX has a “Union” option under remotes but I could not get it to merge two local directories as one remote. One approach would be to serve a common ancestor directory for the directories with your wikis. Technically you can even serve the root directory though that makes me quite uncomfortable and I would not recommend it.
You could also try creating symbolic links to other directories, though this might require root access on Android.
That is exactly the problem, since most (all?) Android browsers won’t let you set the download location. I guess you could use the root if you’re running as localhost. It’s unlikely there’s a lot of exploits built on the assumption that people are running a webdav server. Also, any apps that could use that could already access the same root, so … maybe that’s the ticket.
Lots of good technical discussion and point solutions, some of which I even understand, though still a TW-novice. However, pivoting back to Moosh’s comment above:
… it seems to me that programmers and technically literate people do not quite understand the mass user. This window with the choice of saving methods is a huge barrier for non-technical people. Most people will not take the time to do this, turn around and leave without realizing what Tiddlywiki can give them.
Altho I’m a newbie here, I’ve been a software developer for over 40 years, so I’m more technical than the typical mass user Moosh refers to. I’ve spent 15+ hours trying to understand the basics (Grok TiddlyWiki is a great resource) and making several false-starts at addressing the use-case I described up top.
What attracted me to TW was its open nature, flexibility, and extensibility. But I need something now and it’s still unclear how much more time I’d need to invest to learn and assemble the components to address the synch and save needs I mentioned up top.
My current needs can be met by tools like Notion. As folks on this forum probably know, Notion synchronization uses the, “Keep it online in a single place and manage the use via different devices” model noted by TW_Tones. It’s simple and, “just works”. This is akin to Tiddlyhost, if not for the fact that it reverts the autosave flag.
For “mass users”, is there an approach here that would satisfy the 80-20 rule? Maybe…
Of note is the recent development of a clone button that can be set on tiddlyhost and along with a little support info this may be the most rapid adoption path for many.
Have you tried roam research, obsidian’s software?
Personally I DAV specifically my server’s Apache is configured to DAV on a directory and require (HTTP) authentication when a request does not come from my home IPv4/6 address(es).
I am also careful to close my TW tabs when finished and never open a second by accident.
With this discipline which admittedly does go wrong occasionally I can use any device or sit down at any random computer such as at the museum where I volunteer, or mobile device and use my TW.
I also have some crontab shell scrawl that with a throw of the dice may create a day-named backups of my TWs. So I have a sprinkling of backups that go back a few weeks.
I completely agree a less technical setup that saves tiddlers not whole files and covers what most people want including Android and iOS would be nice but don’t know how.
Maybe this subject needs a dedicated brainstorming meeting.
This is a great practice, if you can manage!
The phrases “when finished” (Do other people know when they’re finished with things? 
) and “never open a second by accident” remind me that we don’t all live in the same universe 
. Distractions and interruptions – plus the occasional “Let me load this in a second window to make sure the plugin/theme/css-hack behaves as expected, before I close this one” moment – can combine to make these ideals aspirational, rather than reliable.
In case anyone else runs Tiddlyhost in browser tabs that can get lost among other windows, I find it helpful to pin the Tiddlyhost account console as first tab in a window, and keep all my active TiddlyWiki sessions within that set of tabs. Then after using Chrome’s “Name Window…” command to name that window (something like ———tiddly, which stands out visually even in a long list), I can use a keyboard shortcut to access that named window. So I’m no longer scanning for my TW tabs like needles in a haystack after work sends me on a wild internet chase. 
All this is a bit of a digression from OP, but my strong vote is for something like tiddlyhost to be the default for new users, with all other save options being for those already sold on the power of the code, and interested in other solutions.
Perhaps tiddlyhost would need help to scale for this – and/or should offer free hosting only for a limited amount of time and/or within a limited storage ceiling. This would still be a much better deal than most “freemium” software.
-Springer
To reduce the likelyhood of overwritting the same wiki from a second tab and browser I have done a fair bit of research. It is hard to document a complete solution but hope I will in time. At least to avoid two tabs of the same wiki its worth opening a wiki in a named tab, follow a link using a target parameter. This sets the window name. You can use javascript to do this as well.
If you pin a named tab it retains its window name.
What I have found is the target/windowname can be set to the wikis domain or filename, then you can construct the target parameter from any link. So via this method if you open another link to the same wiki it will to open it in the same tab. If the target tab has unsaved changes you are warned.
I have also discovered how to capture the browser brand and access a cookie with a device name that once combined with a username allows a unique checkout amonst various tab / browser / device / user combinations.
Virtually every other modern webapp handles saving and syncing between devices with little to no issue, zero user set-up, and zero user input.
Tiddlywiki’s philosophy is not really special in any way that should prevent this from being the case for it too.
Tiddlywiki dosen’t have a back-end, other modern web apps are run on remote servers that handle the syncing and saving.
The bit of Tiddlywiki’s philosophy that makes this not like other web apps is that it is running as a single html file in your browser so that you own and control it, there isn’t someone elses server to do the heavy lifting required to have the zero-setup saving and syncing between different devices.
This argument really isn’t very convincing to me.
Own and control what exactly? The data? The specific instance of the app on my device?
Many apps have encryption to protect your data, have the ability to create txt or md backups, even automatically, so one owns their data.
Many apps are open-source and can demonstrate that the instance of the app on your device is fully under your control, and that this control can’t just be taken away.
I think what is happening is that the way in which the app was initially designed, which was at one time a reasonable means of tackling the issues in question here, is now being confused with the philosophy as to why it was designed that way. We now have better ways of handling these issues, than we used to. The philosophy of Tiddlywiki isn’t in question, but the best way of building an app that works with said philosophy, in 2023.
Convincing or not, it is a single html file. The way that tiddlywiki works means that it is completetly on your device, to make it so that it isn’t the case changes the nature of what it is in a pretty fundamental way.
I am confident both @Elijah and @inmysocks are both correct to some degree here.
As someone who is always investigating avenues to smooth adoption of TiddlyWiki, I have run down multiple rabbit holes that contain possible solutions in which I never found the end (of the rabbit hole).
I believe one day we will have an easy approach and everyone will say “why didn’t I think of that?” when in fact many of us did “think of that” but did not get the support we needed to explore complex issues.
In the mean time tiddlyhost is a good start for new users.
And many of the issues or restrictions that people point out are due to the fact that TiddlyWiki is capable of running as a single HTML file in a browser. As a Linux user I am so glad that Tiddlywiki works the same for me as everybody else. There is a price to pay, portability of this nature does not come for free, Tiddlywiki has to play ball with the way different devices work with internet technology. For instance I have to run the simple RCX server on my Android phone in order that locally stored videos on my phone can show within my Tiddlywiki the same way that they do on my laptop - the reason is that most phone manufacturers set up their version of Android with security restrictions on local file access. That issue is not the fault of Tiddlywiki - it’s part of a bigger picture that goes beyond tiddlywiki and the particular device you are using it on.
I understand some folks get frustrated and also that other more knowledgeable folks want to ease their suffering but some of the criticism stems from insufficient appreciation of the boundaries that Tiddlywiki has to work within. If people really want to remove all those restrictions then they might need to consider writing apps more along the lines of ones people use on their laptops, operating system specific etc but then they will enter the world of porting code from one operating system to another and maintaining that code according to changes at Microsoft or Apple.
I have found frustration myself, but the rewards have been more than worth it.
I disagree, I value the single html file aspect very much indeed.
Your vision of 2023 does not match mine! 
I have the opportunity to change over to the Node.js style Tiddlywiki but I still find the single file the best solution for my workflow and needs.