Side tracking again: Catching multiple exceptions in one catch clause

Many a times people ask me: "Why can't I catch multiple exceptions in one catch clause, I generally end up pasting same error recovery code in all the catch clauses. Why isn't a catch clause like a method signature, where I can have a comma separated list of all the exceptions to be handled?" What they want is some thing like this:

 try{
  //Some File I/O operations here
 }catch(FileNotFoundException fnfe, IOException e){
  //common error handling
 }

The question itself seems to have the answer. If all the exceptions were listed like method parameters, the above snippet of code would mean "Do the common error handling if BOTH FileNotFoundException and IOException are raised" instead of "Do the common error handling if EITHER FileNotFoundException or IOException is raised". The solution probably would be to use the OR operator "||" instead of commas? Some thing like:

 try{
  //Some File I/O operations here
 }catch(FileNotFoundException||IOException||MyNewException e){
  //common error handling
 }

Incidentally, the Oak specification also compares catch clauses to method definitions. From section 9.4:

If you have two overloaded methods called handle, of which one takes FileNotFoundException as a parameter and the other takes IOException as a parameter, java always knows which method to call. It automatically calls the most specific method based on the runtime type of the object.

 private void handle(FileNotFoundException fnfe){
 }

 private void handle(IOException e){
 }

Now, as suggested by the spec, each catch clause can be treated as an overloaded method which takes a subclass of Throwable as a method parameter and no return type. Now extending the method overloading analogy shouldn't java be able to detect which catch clause to invoke? Unfortunately, the complete paragraph from section 9.4 reads:

The question now is, instead of continuing the method definition analogy and supporting overloading semantics to the catch clauses, why does the spec say the first catch clause will be chosen?

One possible reason could be for ease of compiler development. This seems to be an unlikely motivation.

Other possible reason could be for code clarity. What if the java developers start to expect that all the exception handlers that match are invoked? The problem exists with or without auto-sorting of catch clauses. A switch like construct would have been more appropriate then:

 try{
  //Some File I/O operations here
 }catch(Throwable t){
  switchOnClass(t){ //using a hypothetical keyword switchOnClass
   case FileNotFoundException:
    //handle file not found error
    break;
   case FileNotFoundException:
   case MyNewException:
    //some processing for both FileNotFoundException and MyNewException
    break;
  }
 }

Or the other possible reason is because Java's exception handling was based on C++'s (as mentioned in the foot notes of the Oak spec page 26). C++ allows multiple inheritance. So my class MusicStreamingException could extend both MusicPlayerException and IOException. Now assume the compiler see's this piece of code:

 try{
  if(someCheckHere())
   throw new MusicStreamingException();
 }catch(IOException e){

 }catch(MusicPlayerException e){

 }

Both the catch clauses match equally and the compiler has no way of determining which one to invoke. Hence the best policy would be to choose the first catch clause. However, this would never happen in Java as it does not allow multiple inheritance, else the same problem would exist in overloaded methods. Is it possible that this requirement in the spec is only a legacy from C++? And can it be done away with without impacting the existing code?