1. The form of multiple inheritance that Java permits is inheritance of interface only. This is not the same as saying that Java provides interfaces in lieu of multiple inheritance.
   
   
2. Subclasses "marked as implementing their parents' interfaces" by definition are built from inheritance.
   
   
3. The only way to "implement an interface" without inheritance -- which is a contradiction in terms because class interfaces convey type -- is to write a class that serves as a wrapper around another class. In this case you've got redundant interfaces leading to the sullying of the outer interface (there's no reason why an Airport should have a public method collect_quarters just in case it contains an Arcade. Are Airports without Arcades different kinds of objects?), when what you really want is what castaway suggested above; namely an accessor that returns a reference to the contained object. The interface of Arcade should contain methods that take a Person or a FranchiseOwner or whatever and decide what to do based upon the type of object passed in.

All of these examples so far are problems just because the object models themselves are poorly thought out. A Car is not a subclass of Wheel, but more appropriately WheeledVehicle, and a HoverCar is not properly considered a subclass of a normal Car, but probably something like AmphibiousVehicle. As long as such difficulties can be solved by reworking the object model, I don't see any reason to introduce a new and awkward concept of the class interface.