Consider the following scenario:
Session bean Foo is intercepted by interceptor I1, bound using interceptor binding. I1 extends I2, I2 extends I3. Classes I1, I2, I3 declare around-invoke methods (with different names). However, only I3's around-invoke method is invoked.
(Generally, only the around-invoke method of the topmost superclass of the interceptor class which declares an around-invoke method is invoked. If no interceptor's superclass declares any around-invoke method, the interceptor's around-invoke method is invoked correctly.)
The same is true for around-timeout methods.

Such testcase is available at https://github.com/bafco/cdi-tck/commits/CDITCK-376 (SessionBeanAroundInvokeInterceptorTest)

@Stateless @Binding
class Foo { void ping() {} }

@Interceptor @Binding @Priority(1001)
class I1 extends I2 {
    @AroundInvoke
    public Object intercept2(InvocationContext ctx) throws Exception {
        return ctx.proceed();
    }
}

class I2 extends I3 {
    @AroundInvoke
    public Object intercept1(InvocationContext ctx) throws Exception {
        return ctx.proceed();
    }
}

class I3 {
    @AroundInvoke
    public Object intercept0(InvocationContext ctx) throws Exception {
        return ctx.proceed();
    }
}

The aforementioned scenario works fine with CDI managed beans and with interceptors bound using @Interceptors annotation.
With lifecycle callback methods it is more complicated. For example, AroundConstruct scenario works for @Stateless, but does not work for @Stateful.