Multiple rest parameters: Make eagerness configurable or respect parameter matcher

Describe the problem

I was on the fence whether to file this as a bug report or feature request.

Consider the following route, /[...repo]/-/[...path], where repo would be an arbitrary repository name and path an arbitrary file path. Having a path that also contains the "separator" /-/ causes a problem. The repo rest parameter matches eagerly, i.e. it uses the longest match. Given a destination like /repo/-/some/path/-/to/file, the parameters would be matched as

repo: repo/-/some/path
path: to/file

whereas the desired match is

repo: repo
path some/path/-/to/file

Changing the route to include a parameter matcher that ensures that repo doesn't contain /-/ doesn't solve the problem either. Instead of trying a shorter match SvelteKit considers the page to not exist.

Here is a reproduction of the issue: https://github.com/fkling/sveltekit-rest-parameters-demo

Describe the proposed solution

It would be great if there was a way to indicate that a rest parameter should by lazy instead of eager or if SvelteKit would keep trying different slices of the path when the parameter matcher returns false.

Alternatives considered

Using parameter matchers was the alternative that I tried, but that didn't have the desired result. I don't see any other way to achieve this behavior.

Importance

i cannot use SvelteKit without it

Additional Information

I selected importance as "i cannot use SvelteKit without it" because our application has to work on arbitrary (customer) data. I.e we don't have control over the file paths used by customers (we have some control over the repository name mapping).
Somewhat ironically this issue prevents us from browsing the corresponding SvelteKit files with our app in our own repository.

Start with the linked sveltekit-rest-parameters-demo reproduction and trace how the route /[...repo]/-/[...path] matches rest parameters and applies parameter matchers. Verify the current eager match for /repo/-/some/path/-/to/file, then determine how a shorter match could be considered when the matcher rejects it. Done means the route resolves repo as repo and path as some/path/-/to/file.