Here are some of my thoughts for those considering working toward a replacement for the current CHM site.
My understanding of how the overall system works is that its entire state is determined by the descriptions of highway systems in the csv and wpt files built by the CHM collaborators, plus the .list files maintained and sent in by the site's users. When a "site update" runs, all of that information is ingested into the system and placed into a back-end database. I believe the previous database contents are simply thrown out and recreated from these files. It's that database that gets queried to generate all of the pages we know and enjoy: the highway browser, all of our maps, and other stats. There is also a lot of error checking that happens to ensure no bad data enters the system and to flag potential errors (many of which have painstakingly been reported as "false positive" errors over the years).
So I think the site could be recreated in pieces. The ingestion of text files into the database would likely be a program or script run on a Linux/Unix system where all of the files exist, and where both the database daemon and the web server would be running. Initially, all of that extra error checking could be left out just to get something running. Once there is the ability to create the database, writing all those web pages that query it and generate maps and stats would come next. The highway browser is probably the simplest of these (though far from trivial). The Google Maps API does a lot of the hard work, and it should not be hard to pull out the appropriate waypoint labels in order to be plotted. The full functionality of being able to click through to other roads/regions and to show a user's clinched segments could all be placed at a lower priority. The generation of user and overall stats doesn't seem too terrible, though I know a lot of work was done to avoid double-counting clinched concurrencies, and to ensure a user gets "credit" for all concurrent routes on a segment even if only one of them is shown in his or her .list file. Then there's the issue of user maps. I can't remember the name of the library that generates those maps (like those quoted upthread here) but I'm sure we could figure it out. Then it's a matter of drawing those maps, on demand, when users are navigating the site. I'd also be interested in seeing an option that works more directly in Google Maps, but I'd hate to lose the simplicity of the maps the site produces now.
I have seen requests here (and many times in the past in the CHM forum) for a clickable interface to plot your travels. While I'm in the camp of those who'd rather edit a file than try to click around on a map, I do think it's a nice feature to have. I'd see it as almost a standalone piece of the project. Yes, it would need to read the database to get the information from the route descriptions (the CSV and WPT files), but I see this as something where you can upload your .list file, view it in a map/tabular environment, and your result is a new version of your .list file. I envision something where you could zoom in on places where you are looking to add your new segments, and do something like drag from a starting waypoint to an ending waypoint. It would then show you what segment would be added and if you approve, it would be added to your .list file.
One of the most important features (and one I know was in the works on the existing site) is the ability for users to be able to upload their own .list files. There are a surprising number of complications that arise to support this, most importantly that there would need to be some sort of user/password system to ensure users could only update their own .lists, and that we would want to avoid the potential for spam and malicious submissions that could expose security flaws or result in denial of service attacks. But this does seem like an important feature, and one, if in place now on the current system, would allow the users of the site to continue using it to update their travels, even if no highway data updates were able to take place.
Then there's the issue raised in some recent posts about who can update the highway data. I think there are many models out there, with varying degrees of success, where some sort of trusted data is maintained by a community. It seems such a model could work with this project. We already had this, though in a limited fashion, with the peer review process of new systems, but the single person bottleneck remains for getting those reviewed updates live in the system. The project could expand more quickly the more people who were able to review and correct existing data and propose new data to be added, but I'd hate to see the overall quality of the data (accuracy of routes, appropriate density of routes, consistency in naming conventions, etc.) suffer. There are also issues of making sure sources are cited, and sources used are not copyrighted.
Even if the current system returns to a more active status, I think efforts to replicate and possibly improve upon its functionality are worthwhile. But even if we could find a few people with the appropriate skills and experience to put some time into it, it would be quite some time before we had something approaching what's there. As I said before, I am holding out hope for the existing system and that it will evolve into a system without that single person bottleneck. If something like a .list editor were implemented, or a nicer highway browser, or new ways to view your travels, they might be adopted by the existing site.