Assume not the name of the file/path, but something more like a logical name like:

    Foo\Bar\Demo\Css\Template.css

With PSR Path Mapping, you could setup a map like this:

```json
{
    "Foo\\Bar": "src"
}
```

So if you ask for:

    classpath:///Foo/Bar/Demo/Css/Template.css

... a potential map based on the input (`Foo/Bar/Demo/Css/Template.css`) against the map (listed above) would result in a potential match:

    src/Demo/Css/Template.css

If it exists, it is considered a match and that value is returned. If not, we checks other mappings, in order, until the algorithm finds a potential match that actually exists on disk... and then returns it. 

For example, another package might have registered another mapping like this:

```json
{
    "Foo": "src"
}
````

The algorithm would evaluate this rule after the first mapping (since it is a less specific mapping), but would still check the original input:

    classpath:///Foo/Bar/Demo/Css/Template.css

... which would result in a new potential match:

    src/Bar/Demo/Css/Template.css

If it exists, it is returned.

Again, the fact that we are using `classpath:` scheme here is besides the point and why I would rather we not talks about things in terms of PSR-R. At least not *right now*. :)

Classpath is only a PSR-R concept and for all we know PSR-R may never become an actual thing. :) The important part in my mind is the algorithm and the fact that the logical mapping => physical resources is what we get locked down.