@jducoeur, that’s an excellent question. Actually, I don’t have an example. I was afraid to use super.m and expect the same semantics as CL call-next-method. But according to the discussion, it seems to be intended to work the same way as I expect. My hesitation came from discussion I had earlier saying WARNING don’t depend on multiple inheritance or linearization.
In CLOS linearization is indeed seen as a dependable feature, and its consequences and limitations are all understood and accepted by most intermediate and advanced programmers, so much so that nobody even cares about or mentions the diamond problem. Moreover, the CLOS metaobject protocol, allows users to create a subclass of standard-object which overrides the class linearization method on a per-application basis.
Since in CL, there is no concept of final class or final method, this causes programmers who implement libraries to be very conscious to allow classes to still work when people extend them.
Another part of my hesitation of using super.m was because of comments in this post. Which led me to believe that delegating to the next method was a bad idea, and I should refactor my code when I discover a need for it, and for example use composition a chain-of-responsibility pattern rather than inheritance.
Nevertheless, since it seems super.m works as expected, perhaps I should embrace it and just start using it, and see what happens.