I was thinking about this more today and it hurt my head. In general I was thinking about what it would take to add a moodle portfolio plugin to moodle.
And it would want to implement the same functions we have currently... but they would have to live in portfolio/type/moodle/lib.php
But we already have those functions, in portfolio/type/mahara/lib.php - but they're only the send version.... that is: In order to make permit_rpc_call or whatever that function was allow me to call the mahara xmlrpc methods remotely, it had to be able to find local implementations of them, which is a fallacy (symmetry). So to make that function happy, I created them in the mahara plugin as local (not xmlrpc) functions, but then as soon as I need to implement them as xmlrpc functions (eg in the case that moodle starts being able to be a portfolio server as well as client), we get collision.
This seems to be all caused by the assumption that server == client - eg, both are moodle, so both have the exact same list of rpc functions available. In the case of portfolio, server and client functions are implemented in different places. Currently send_content_intent and send_content_ready are only implemented as rpc functions in mahara, but the mnet client code in moodle demands them to be able to be found locally.