(This post was rather long, so to summarize: (1) I think I can deal with the technical issues you mention and that it would be worthwhile to do so, but (2) the "spirit of the original" issue is very significant; I'd try to maintain it but it would never be a perfect attempt by the nature of the problem. (3) I hope you'll allow Delver to continue on in some way rather than let this unique and valuable work fade away, but (4) if you think it's better that it does, it's your call and I respect that.)
That does sound problematical. In a hypothetical OSS project, it would probably be good to rewrite the editor (say, in Python, which apparently we have a mutual interest in, I see from looking at the other forums here).
Re: Current State of the Code
That also sounds like a source of much work, although not outside of what I expected; Delver always seemed so well integrated into the Mac way of doing things, interface wise, as compared to other games. The interface never seemed to get in the way of the game, like it does even in many modern RPGs. With an eye to porting it to other platforms, it might be best to write a library overtop of a cross-platform graphics library like SDL that emulates the functionality of the Classic Mac OS's GUI, as used in Delver. Yes, this would also be a lot of work, but I have done similar work before and indeed enjoyed it. Most of the time. (I do now hate PICT with a passion...)
I have CodeWarrior, and, thanks to the inconsiderate non-portability of the code generated by the students in the class I TA'ed for, lots of experience fixing "odd" C++ code work with gcc. So don't worry about this one - compared to the time you have invested in the Delver codebase, I'm sure fixing this problem will be very minor. (Again, relatively speaking)
Re: Unneeded Optimizations
Hmm, I'm studying systems programming and I love stuff that saves every byte. Not that I'd use it in places like an RPG, where it would be introducing complexity that is no longer justified, but I'm not afraid of bitwise math. Same goes for endian problems: I've dealt with that before. I also expected it to be an issue, given that in the day Delver was written, it seemed to me and many other people that a Mac with an Intel CPU in it would be an abomination unto Apple. Regarding assembly language parts: I don't know what parts are in assembly (I'd guess graphics or the runtime for the scripting language), but that doesn't worry me too much either. I admit I've never done PPC assembly though, beyond a little tutorial that was in MacTech or something ages ago.
Re: Work for you.
Well, that's a legitimate concern and I respect your judgment on these matters (especially the "spirit of the original" point, which I will discuss momentarily). Two minor points though - if you want, I can do the work of setting up a code repository, and if you don't want to help with the proposed project beyond the already great contributions of writing the code to begin with and pruning proprietary code, that's your call. After all, the whole point is to turn over the work of maintaining it over to someone else. It doesn't imply that you have to do anything after that. On the other hand, if you want to be the "Benevolent Dictator for Life" of the project, it's fine with me too. But clearly there is a time spent/project control trade-off here.
Re: Spirit of Delver
I'm not offended by this issue at all. I regard it as the most significant of all the ones you raise, because with the others there really isn't any question that they couldn't be fixed with time and effort. (Rather, the question is: is it worth the time and effort?) I'm not sure what you consider the spirit of Delver, but these are the things that I see as making it up:
1. The engine is apart from the scenario. This separation is the Right Thing, and as far as possible scenario-specific data should be kept out of the engine.
2. A strong and flexible scripting system. This is also a major win because it allows you to, essentially, move much of the work of writing game logic into a language amicable to that purpose. Nowadays it might be better to embed an already existing language like Python for scripting, but the Delver scripting language as it is seems to work fine and I don't see a need to replace it as a goal. (Obviously that would require all the scripts in a scenario to be rewritten as well...)
3. Careful attention to the user interface, making it both nice-looking, easy to use, and conformant to the user's expectations. For instance, dragging items by their icons from one container to another, or onto the screen; contextual menus for applying different actions to game characters, and so forth. This is way better than most RPGs even today. They stop at "nice looking" and finish with "easy to code."
(There are other things in Cythera that I consider great ideas or essential to it, but I'm not sure at what level of Cythera they exist, that is, I don't know if they're part of the scenario or Delver. In any case we're not talking about a Cythera II, which is entirely your province. I am not asking to do that nor do I consider myself qualified to do so: Cythera is your world.)
You may have different feelings about what constitutes the "spririt of the original." Obviously only you know for sure. The project would be different than if you were the one continuing it, there is no way around that. I'd try to be as true to the spirit of the original as I could - certainly, I'd be responsive to any suggestions you wanted to make in that regard. Years ago, when I was forming my ambitions of becoming a programmer, we exchanged some emails on the topic of RPG design and Delver. I don't know if you remember that, but I think they had a big influence on my ideas about how an RPG engine should be.
So, if you don't think anyone else can be faithful enough to the spirit of the original, I understand and respect your choice. But realistically, it doesn't seem like the project is going to go forward with your limited free time to work on older stuff like this. It's usually more interesting to press forward, and no doubt more economically rewarding. (That fractal stuff you're working on is pretty neat, by the way). The question becomes, "Is it better that Delver come to an end, or be continue under someone else's control?" As I said, there is legitimacy in both answers, and it's naturally affected by how well you think the prospective caretaker's understanding of the program's spirit aligns with yours and how likely it is that some other resolution will manifest.
I do ask, though, that you not underestimate the value of the code. Even if considerable portions needed to be rewritten, this is something that represents a lot of your work. Letting it fade away because of compatibility problems seems like a truly unfortunate loss, especially because of its uniqueness.