I believe that a rewrite is actually pretty necessary. And while I'm not really a "developer" of Spring, despite my name on the credits (trust me, in the end I contributed maybe 10 lines of code) I have read a lot of the source, and I can understand the urge to move on- and not just for novelty's sake.
Don't get me wrong- Spring could have more and more tacked onto it, gradually pushing out towards the ultimate MTR stuff. It could. However, the time it will take to get there is, I think, more than the time it will take to get there with a fairly clean start.
The developers do not plan on re-writing everything, either. Many of Spring's core libraries and processes are slated to be ported, because they work. However, the fundamental crux of the matter of this is simply put:
Spring was meant to be a port of TA. Not a universal RTS game engine. While it's a heck of a port, and in many ways is superior to the original, now that certain features are in place, it's locked into a fundamental game design, and that's not something you can just wish away.
There are two ways to achieve that.
One is come up with a brilliant game design that is new, and shoehorn it into Spring's existing code. That requires the developers to be brilliant game designers, not just great developers. I have yet to hear JC, Tobi, etc. tell us that they are basically awesome game designers, let alone see them put out a game design. I don't doubt that they have ideas, like many people do- but ideas aren't finished games, and we'd all be waiting to see if whatever game design they came up with was both fun and brilliant... and allowed the modders enough room to continue to innovate.
If they'd chosen that path, I'd have set their email addresses on fire, spread the ashes, and immediately declared that I'd maintain Spring if nobody else was willing
Instead, I'm helping with the new project, insofar as my brand of grumpy sarcasm is helpful
What they're building is still very much vaporware, but the premise is what I have been wanting for all of the decade I've been making games. They're talking about an engine that is fundamentally designed of parts (called Entities) that be built, interconnected, destroyed, and talk to one another, creating gameplay. If executed well, we could have an RTS engine that could do almost anything that somebody was willing to code- an engine that could grow from small examples into very large projects as people contribute more and more roots and snippets.
Want multiple resources? Use this module, and feed it parameters at "go". Want pre-defined starting armies? Use this one. Want something to take X time to build, with no "helpers" allowed? Use this one. And so forth.
In short... while designers are not going to be able to turn this thing into any possible game without tearing it up, just about any concept for an RTS should be achievable, and we'll finally have an engine where the, "but if I only had this" list gets shorter every time somebody contributes, and people can contribute shorter modules for specific functionality, instead of having to read and comprehend large sections of the core source to actually have a clue as to what interacts with what, and why(see my struggle to write the Flamethrower code, which Yeha eventually re-wrote into the Colormap concept, to get an idea how painful this is when you're just starting out).
Stuff like formation movement, multiple resources, unit limits, and other things- the hard-core game-design stuff that Spring sorely lacks... will be very much possible. Could it all be shoehorned into Spring? Maybe. But I think not, honestly- there are a LOT of things that were assumed when Spring was written, and un-assuming them would be a lot've slog through not-very-interesting-land.
Do I think this will be easy? No. Possibly fail? Sure. Worth trying? Yes.
I've seen this happen in a lot of small games (and was a victim of such attitude, too :))
).
)