Thanks we will discuss this point with esteban and igor.
I think the underlying issue is that a "Deprecation" is always signalled, regardless of the state of "Deprecation raiseWarning", and the actual processing of e.g. logs, transcript, etc is deferred to "defaultAction". This makes side effects somewhat unpredictable when intermediate code catches Warning exceptions (from which Deprecation inherits). I think the fix is to not signal exceptions when raiseWarnings is false.
A similar problem happens with unit tests which call deprecated code. These tests fail silently when "Deprecation raiseWarning" is false as "TestResult>>runCase:" catches the Warning exceptions. I think they should pass. It's seems useful to have the tests fail when raiseWarning is true.
For myself, I've just moved the contents of "Deprecation>>defaultAction" into "Deprecation>>signal" with the obvious adjustments. I'm not sure this is necessarily the best way.
Would appreciate any comments, conclusions etc from folks that know more about this stuff than me :)
Cheers, Martin