I noticed that providing overview.yaml to define the main page doesn’t work.
I’m not sure this ties into the OP’s question. If it’s a separate issue, would you mind creating a new topic for it? Happy to continue the discussion there.
Thing is, a page called overview is there by default install
(not sure if the wizard created it?) so overview.yaml didn’t override it.
Also I’m not sure about how OH prioritizes when it has different inputs (from .yaml and JSON-stored UI definitions).
Same as with things & items.
That used to be coincidence (which provider class loaded faster on startup) until (I believe) it was
fixed via startup levels some time ago, but not sure about new yaml/file UI definitions.
I think somewhere along the lines, possibly the wizard, created overview and home. You need to first delete them - backing them up if necessary. They are deletable since OH 5.2.
The name of the yaml file has no role in anything. What matters is the page uid, so you need to create:
version: 1
pages:
overview: # <-- This is what matters
<start with the one you copy pasted from the UI>
home:
<ditto, copy from the UI>
For more info see Home & Overview pages
If anything is unclear in the docs, let me know so it can be updated / improved.
Ideally, there should be no duplicate UIDs across the entire system. That way it doesn’t matter which one loads first. Usually the UI one seems to load first.
Just FYI, our demo server at https://demo.openhab.org is using YAML files to provide the vast majority of its UI:
That’s fine. But yes, last time I tried, I could not create the ‘overview’ UID page via .yaml file
Uuuhh … nah that you cannot make a requirement to users. If it’s really coincidential which one loads first we have a problem in the making.
We used to have that situation for ages in the early days of openHAB with Things and Items created via files vs UI. Dark agaes I don’t want to drop back into 
Where’s the managed:pages and managed:widgets startlevels ?
If the UI (editable) overview page still exists, the YAML one won’t load. You’ll need to delete the UI (editable) one.
I know. But this doesn’t work zero-touch (i.e. without human interaction) when I want to install some OH instance from scratch.
How so? AFAIK, the UI-generated overview / home need to be created by human touch. From scratch they shouldn’t exist so the file-based ones should simply work on a new installation.
You’re right, my bad. Just re-tested, it actually works on a fresh install to (auto-)put overview.yaml there.