post-destroot like callback inside muniversal destroot before merge?

[Michael Dickens]

For various reasons, I decided over the weekend to see if I could coerce
py*-scipy into building as +universal, and I've pretty much succeeded
and it's not much of a hack either -- mostly just getting the build
arguments and environment correct and using muniversal-1.0 to do the
background heavy lifting.

Except for one "little" detail: Merging fails because one of the .py
files and many of the .pyc files are different -- and, these file types
are not handled by muniversal.  Even if I added code to muniversal-1.0
to handle .pyc files (either delete them since they are not required, or
recreate them from the hopefully unique corresponding .py file), that
still would not take care of the .py files.  Further, the way scipy
installs does not allow be to modify files between installation and
muniversal's merging.

For the purposes of verifying that the merge would work if I corrected
the .py files (just tweaking comments) and remove the .pyc files, I
copied the first part (arch-specific destroot) of muniversal-1.0's
"variant universal :: destroot" into a local (to my Portfile)
post-configure stage ("configure" does the actual building instead of
"build" as is usual for python ports; it's complicated).  After the
various arch destroots are installed, I then tweak the files as needed
and then clear out the "destroot.*" variables (to disable the normal
"destroot" proc from actually doing anything, since the files are
already installed).  At least in this case (for scipy), the actual
muniversal destroot merge worked as hoped/expected.

The aforementioned hack works, and it should be reasonably robust -- but
it's ugly.  What I'd much prefer, and effectively what I implemented in
this hack, is a callback inside muniversal's destroot, which takes place
after the arch-specific destroots but before merging.  This callback
could be muniversal-1.0 specific, or just the Portfile's post-destroot. 
This callback would allowthe tweaking of arch-specific destroots much
like non-universal post-destroot does; it could be arch-specific, or a
general one for all destroots.

I have no idea how to implement this, nor if this is a behavior that
MacPorts devs would find useful.  Thoughts / comments? - MLD