mgiuca: Do you think this is something we should add to the spec?

Yes, but I think we should explore the space first.

As discussed yesterday, we may want to add an explicit manifest option to exclude part of the scope, and then prevent install of two apps with overlapping scope (still allowing nested apps by having the parent app exclude the child app scope). That would certainly result in a spec change and a change to the "within scope" [1] algorithm.

If we don't do that, it's a bit harder to see how we would change the "within scope" algorithm because it would become a function of what apps you have installed.

[1] https://www.w3.org/TR/appmanifest/#dfn-within-scope

For deep-linking on Android (pre-WebAPKs) we use the longest scope match (WebappRegistry#getWebappDataStorageForUrl). However, I'm fairly sure it's arbitrary for WebAPKs (WebApkValidator#queryWebApkPackage).

Ya, I think when I wrote it, WebApk just returned the first one that matches and it's fixable but note that its not sufficient due to how verified intent handlers work on Android M. Android has an API that lets you see who can handle an intent (queryIntentActivities). However, if you have an app with a verified intent handler, android returns only that app if it's eligible. The way to work around this is to set the context of the intent when querying the package manager to be the current app. So effectively we end up with two different queries:
1) who can handle this url
2) can *this* app handle *this* url

Number 2 is handled by WebApkValidator#canWebApkHandleUrl.

"Similarly if the user is in https://www.example.com and navigates to https://www.example.com/foobar we should open an app window for the second app."

Because of the complication listed above, making this work is probably a more significant change cause we could no longer just rely on android intent dispatch and would have to write custom chrome code. 

"As discussed yesterday, we may want to add an explicit manifest option to exclude part of the scope, and then prevent install of two apps with overlapping scope (still allowing nested apps by having the parent app exclude the child app scope). That would certainly result in a spec change and a change to the "within scope" [1] algorithm."

Unfortunately I don't think this is compatible with android intent dispatch in any straightforward manner and likely to hit complications above.

Sad. I'll have to think about this some more. This isn't a good situation to be in (multiple apps handling the same URLs) and I don't think we should compromise the spec behaviour around the limitations of the WebAPK model.

Questions on Android:
- What happens today if you have two WebAPKs installed with nested scopes? Which app is chosen to handle URLs? (Or do they simply both appear in a picker.)
- Is there any callback-like API for an app to programmatically decide whether or not it can handle a particular URL? (Then we could program the WebAPK to reject any URLs that are in the "exclude" set.)

If we are in a situation where Android *forces* us to show a picker for "https://google.com/maps/foo" asking the user to pick from Google Search and Google Maps, then I think that's clearly bad behaviour, caused by a system limitation of Android. The right thing to do would be to spec that user agents SHOULD NOT [rfc2119] do that, and unfortunately be forced to do it on Android (but do the right thing on other platforms).

I haven't 100% verified in code but my expectation is we show a picker.
No, there's no such API.

We no longer link capture in the initial version, so this isn't an issue in 67.