I respectfully disagree. The SRI spec doesn't tell you how to implement it [1]. In fact it allows implementing everything you described. A browser could decide to completely disregard the src= element and load the resource based on the hash matching a file already present in cache (no matter what CDN it comes from). The end result is equivalent: the same content is interpreted. That means no more downtime when a CDN is down, no more cache fragmentation, and so on.
On a side note: there is no need to match the file name, only the hash matters.
[1] http://www.w3.org/TR/SRI/#conformance: "Conformance requirements [...] can be implemented in any manner, so long as the end result is equivalent"
Accidental collisions in a 256 bits space are not practically possible. You have 2^100+ higher chances that your CPU or RAM accidentally corrupts some data that leads you to execute the wrong JavaScript anyway, or that a meteorite falls on your head at this instant. It is utterly pointless to check the file name for this reason. If you worry about SHA256 collisions, you worry about the wrong things. That's why all modern crypto used everywhere around you already assumes SHA256 collisions are currently impractical.
All you need to do is to have an option to migrate to stronger hashes the day attacks start weakening SHA256, which is why SRI uses a "sha256-" prefix so we can migrate to stronger hashes when needed.
On a side note: there is no need to match the file name, only the hash matters.
[1] http://www.w3.org/TR/SRI/#conformance: "Conformance requirements [...] can be implemented in any manner, so long as the end result is equivalent"