For multi-catches, 14.20.3 does not require an access check on the inferred type of the exception. In the program below, 14.20.3 just says "the type of e is the lub of E1 and E2", without regard for whether EBase is accessible at the point of the multi-catch.

    class Exceptions {
        private static class EBase extends Exception {
            public void m() { System.out.println("EBase::m"); }
        }
        public static class E1 extends EBase {}
        public static class E2 extends EBase {}
    }

    public class MultiCatchTest {
        public static void main(String[] args) {
            try {
                throwSomething();
            } catch (Exceptions.E1 | Exceptions.E2 e) {
                e.m();
            }
        }
      
        static void throwSomething() throws Exceptions.E1, Exceptions.E2 {
            throw new Exceptions.E1();
        }
    }

This program compiles without error, which is wrong, and runs without error, which is very wrong. The class Exceptions has a private member class EBase, which should be inaccessible from the body of a different class like MultiCatchTest. However, EBase is compiled to a top-level package-access class, so is accessible at run time for the exception handler in MultiCatchTest. Statically forbidding the exception handler from accessing EBase.m would sidestep the problem of infelicitous compilation (private member compiles to a non-private class) allowing illegitimate access.

The corresponding javac bug JDK-8289975 shows a similar example program, where class Exceptions is in a different package than class MultiCatchTest. The program there compiles without error, but gives an IAE at run time. Statically forbidding the exception handler from accessing EBase.m would sidestep the problem of inconsistent behavior between compile time and run time.