I have been able to develop a method for removing these internal repdefs. (This method has not been approved by SAP Sybase. Use at your own risk!)
As a precaution, I backed up the RSSD. If all else fails, you can restore the RSSD and rebuild the queues. This worse case may require running rs_subcmp on databases in question or re-syncing them following the rebuild of the queues.
Here are the basic steps.
1) On source repserver, suspend connection to the affected server.database. Suspend log transfer from the source server.database.
2) Shutdown the repserver
3) On the RSSD, delete rs_drp... columns in rs_columns for the specific rs_drp.. objid. Delete rs_drp... rows in rs_objects
4) On the source dataserver, change to the affected database. Run sp_stop_rep_agent for this database. Issue the dbcc settrunc ('ltm','ignore'). You have now started the process of restarting the replication from the last transaction.
5) On the RSSD, run rs_zeroltm dataserver, database
6) On the dataserver in the affected database, set the truncation point to valid - dbcc settrunc( 'ltm', 'valid') - followed by restarting the repagent (sp_start_rep_agent).
At this point, you have reset replication to restart fort this database. This has removed any reference in the RSSD to the replication of the rs_drp... (dropped) subscriptions and as such, the repserver no longer crashes.
7) On the repserver, resume log transfer from the server.database and resume the connection to the server.database.
If there have been any transactions in the primary database, it will be necessary to resync the target databases. The rs_subcmp may also be an alternative.
I should note that just re-syncing the downstream targets will not correct the problem as the data in the RSSD is related to the source server.database and will not be cleared until either the RSSD is restored or the repagent is set to restart replication and bypass the bad queued data.