You spoke of Perl programming tricks and techniques and of patterns and strategies (as I hoped you would).

Let me try to summarize the lessons learned.

On Perl programming:

• dws ... storing the class name in each instance is overkill.

  True enough. I could store it in a package variable

      my $thisClass = "MyModule";

  In addition, I could encapsulate this variable by placing it together with the module code inside a block.

• Revelation ... using Universal::isa (UNIVERSAL::isa ( VAL, TYPE ) ), which returns true if the VAL is the name of a package that inherits from (or is itself) package TYPE.

  Good point. I expected that there would be a way to check the class name better than my clumsy

      if ref $_[0] && ref $_[0] eq $_[0]->{class};

  and I have seen UNIVERSAL::isa mentioned in print before. Now I could write

      if $_[0]->isa($thisClass); 

• Revelation ... sub return_with_object {...} ... That function creates a blessed object, if there is not one to begin with.

  Looks interesting, but maybe more than what I need right now.

• blssu ... Perl OO is a lot more flexible than most people are used to. Two self-imposed beliefs are tripping you up. First, you can have more than one package in a module. Second, you don't need to bless your object to the package the constructor is defined in.

  Sure, I knew this, from reading the Camel Book. But now I see how it can apply to my case.

  ... The constructor for the object API is defined in the old module so the actual class name of your new object API is hidden from the user.

  Indeed, my unstated objective was not to have new names for subs promoted methods or for the new OO module.
  Your suggestion seems to meet this goal nicely. It also dovetails with sauoq's and adrianh's.
  BTW, you look like a Monastery novice who is not a Perl novice.

On strategies for morphing:

• sauoq ... It is far too easy to break the original code in subtle ways.
  adrianh ... write a new module for the OO stuff and have it use the old module under the covers.

  Fundamentally right. It seemed a bit heavy, until blssu showed how to do it in one compact module.

• adrianh ... If it doesn't have one already, write a comprehensive test suite for the original module - so you can be sure that you don't break anything during the move.
  (and I really mean it about those tests :-)

  I agree 100% (maybe more). The old module does not have a test suite, but it will have one soon.