This is exactly what I was thinking. And if you mark it as default property you wouldn't even need to do the "routes: []" awkwardness.

If you have routes as objects you could have an "active" property on the route, removing the need for this invokable.

Not really, the point of this property is to query whether a full URI is on the stack. The login route being on the stack somewhere is not the same information as whether /home/login or /apps/login are on the route.

if is a publicly accessible property, it should be apublic and documented

This is an internal struct for keeping track of internal state and to have a C++ representation of a a QJSValue that may not correspond to a PageRoute object declared by the user. Compare by struct values instead of compare by pointer reference is used here as well.

The global property is already gone, this is the per-page property

componentComplete is used to ensure that everything is parsed only when QML is done, not when the object is created

The initial route can have data

I find all the "/" in the examples confusing, not sure is a good naming convention (and works prefectly without having that /, and i don't necessarly care what the convention in other frameworks is).
in the hend you can't push directly something like "/home/login" as a single string so doesn't really make sense as paths, i would prefer examples had simple strings as route names, so your route would be indicated as ["home", "login"]

I wouldn't expect a verb like navigate to be always destructive.
if the route happens to be the same, then the function should be a no-op
if the current route is
home/foo/bar and i want to navigate to home/foo/baz i would expect to remove and destroy only bar, keeping the first two pages

if the new route is foo/bar/baz, should just push the new one keeping all is there

I know we are fixed to columnview now and its fine, but i would prefer the property being called pageStack like in applicationwindow (in reality i would like both being called pageview but it's too late) which doesn't assume which it is, if sme day we would like to support stackview or whatever else we wouldn't have a sore point in the api

also, to the property assigning the pagerow (which will look for the columnview internally, but not exposed trough the api)

newlines!