Thank you both...invoke(bar,(Fu,),f) has exactly the semantics I was looking for (esp. being able to specify which type constraint I'm loosening in the case where there are multiple args participating in the dispatch.
As for Keno's suggestion that I refactor into a primary/secondary method pattern, I can see how that would be the right solution in some cases, but doesn't feel like a good fit in my present case; my subtype's "around" method is only there to maintain additional invariants imposed by the subtype, and having an additional function that does the "actual work" without maintaining the invariant feels...icky. Thanks again for the prompt replies, -- MarkusQ
