The countries are not a problem. But usually you don't want blank data right after the state border, that's the point.
I also have this idea of using a clustered setup. I also don't want my Twisted knowledge to rust. The company I'm working at announced an R&D lab for noncommercial, spinoff and hobby projects, so maybe someday I would talk them into building the most efficient OSM rendering farm in the world.
Seeing demise of t@h, OTOH, I'm a bit skeptical about this one.
I don't know a thing about layers. All tiles are single layer, with all details already burnt-in. The point is that in OSM default stylesheet has better contrast overall, and maps rendered with it have proper city/village/whatever boundaries rendered, which my maps don't.
imposm, on the other hand, handles data much more efficiently on your average desktop/laptop hardware, my humble entry-level Thinkpad would crunch all of Europe in around 4 hours which is fast. The problem is, tables, tags and so on as produced by this tool, are totally different from what osm2pgsql provides. So, in fact, I had to google "imposm osm.xml style compatible" and so on, getting irrelevant things at the top, until I've found OSM-bright and Carto. Then, the stylesheet produced makes what you see on the screenshot. The OSM XML is so big that I don't have the faintest idea what to tweak so it would work. Or maybe I would leave osm2pgsql running for a weekend with the latest Europe data, set up a cron job to incorporate differences as they flow in (osm2pgsql data allow this, imposm don't, AFAIK), and then render particular countries (so they have consistent data at the borders and so that anyone would be able to merge tilesets as he wishes).
rendering would become so complex that your phone would die of overheating / battery drain very fast.
Another way is to use OSM data (maybe in PBF format) to do the same, but I'm wondering how much study one has to invest into it, and how efficient would it be in the end. Wouldn't it be that in addition to quite big OSM datafiles there would need to be an even bigger index to efficiently search for needed data fragments?
Tiles are simple, on the other hand, and straightforward. You don't need to muck around with projections all the time, resorting instead to simple Cartesian arithmetic.
By some clever use of normalization and a few lines patch for ModRana I have been able to slim dataset for the whole of Poland with zoom level up to 15 and select cities up to 18, from 4792M to 4589M. That's the whole 203 megabytes less, with no performance