I have lots of ideas, but I'm not sure I have enough time to even articulate them fully, let alone implement them.  Here's a first stab:

• A highly portable, core computation engine which doesn't depend on anything outside the standard libraries.  I don't think that a "validation only" engine is any less code than a block generating engine, so I see no reason for any bifurcation in that respect.
  
  
• A cross-platform APPEND ONLY database for storing blocks. There's lots of interesting stuff happening in the NoSQL world that would work well here.  I think it makes sense to piggyback on some other open source; the key is to find something that is lean.  Most of the NoSQL world is focussed on speed, and that's far less of an issue here.  Ideally, a library for reading the block list would be a separable component; there are some interesting BTC applications that don't need access to your wallet.
  
  
• A plugin architecture for alternate hashing engines.  Faster hashing means generating more coins for yourself.  If BTC takes off, there will be a market for fast hash engines.  Ideally, this plugin engine should require that the plugin returns ALL computed hash values, not just successes.  That way the core engine can randomly confirm that hashes are being properly computed.  (Making a fake plugin which doesn't actually do all the hashes it claimed would be really simple...)  Creating a plugin system here means fewer forked clients and much less maintenance for users and the community.
  
  
• The main "bitcoin" process should always be a daemon.  You could configure a client to quit the daemon when it shuts down, but the client and the daemon should be separate processes.
  
  
• WALLET IS ALWAYS STORED ENCRYPTED.
  
  
• A secure RPC/web service interface for clients.  Maybe based on OAuth?  The OAuth style model is best here, though.  The key thing is that you don't want to require clients to have a copy of the user's password.  No siree, Bob!  Local machine connections could be authenticated by the daemon directly, remote connections would need to provide a simple HTTPS form for authentication.
  
  
• Separate read-only/read-write permissions.  Read-only permissions could be used to check balances, verify payments, check confirmation counts.  Read-write would only be necessary for applications that send payments.  There are some useful applications which only require read-only access (eg. notify when a new payment comes in and is confirmed), but I'd be less likely to want to run a third-party app like that if I had to also give it permission to send my coins to some untraceable address!

A key design goal here is compartmentalization.  The compute engine is portable so it can be shared across platforms.  The hashing code is pluggable so that custom hash engines don't require forking the entire project.  Multiple clients can be written for each platform, and can all be safely run at the same time talking to a single core daemon.