Look into hosting tiles on archive.org
look into rendering and hosting tiles on the wikipedia toolserver
Build a local api proxy that you can tell it to publish your changesets to multiple server, to your blog and to sync and resolve changes and conflicts
Look at the google maps api and see if it can be supported by osm.
we want real time rendering. we want to be able to have changes rendered immediately.
we want to subscribe to peoples edits via georss and have them rendered on top of other maps.
We want to support many layers of the map and render them separately. we want to be able to combine layers and have masks for doing that.
we want the Ability to use GIT or version control to manage small sections of the map.
We want to be able to integrate photomaps from services like picasa, twitter, flickr and panoramia, wikipedia. we want to be able to make layers from photos and also be able to convert some to nodes. we want to be able to publish them again annotated back to other systems (tag them in flickr based on osm data)
Using semantic web to describe the structure of the tags. Include reasoning engine to evaluate properties. see also linkedgeodata.org and schematroll and other schema tools
We want to view the changes in an area, like the itoworld tool does, but as a central part of the system. http://www.itoworld.com/static/openstreetmap_tools/osm_mapper.html we need to be able to subscribe to the changes as a georss feed
for remote places, with bad internet connections, we want to have the main server to be local to the users in the internet. Some users might find that the server in london is slow. they will want simple tools to setup and host a local cache and CPU pool that is used in the larger OSM scheme.
the changesets basic data could be broadcast in an irc channel with a special syntax to describe what area is affected, what the contents are, what conflicts occur and a link to the data. this could be subscribed by simple filtering on the channel.
you could post the basic data about an osm changeset using a short bounding box the basic data in it and a link to the data in twitter and then aggregate the data. this could use a geohash or something similar to easily select the area.
we can use geohashs to split and sort the data for easy selection. If the osm data is split into a directory structure based on its geohash then it would be easier to select data based on its location without a database server needed. such a split dataset could be hosted on a simple ftp file server.