There have always been some monsters in D&D that are meant to fight the party alone (at least, the first time you encounter them), so it's a safe bet that the kinds of monsters we refer to as "solo monsters" in 4E have a strong place in the future of the game (but did "solo" monsters exist before 4e, or is this a "feature" that 4e ripped from MMORPGs? Do "solo" monsters, monsters built and powered far beyond their racial norm, really have a place in D&D. Aren't dragons and the like effectively "solo monsters", depending on the party's level?). Right now, when it comes to monsters, we're looking to build each monster to provide the best expression of that monster's traditional experience, and in many cases that means squaring off against the heroes without any other creatures in the mix (which is pretty much what I was talking about above - if your need a solo monster for a bunch of gobbies, use a bugbear).
As far as "improving solo monsters" goes, there are some things we have learned over the course of the last few years (4e era) that are vulnerabilities that can plague solo monsters; being taken out of the fight by conditions like daze/stun/dominate (is that really so bad? if it happens to be taken out quickly by smart players, doesn't that speed up combat and gameplay?), or lasting too long so the fight starts to drag (from what I've heard, that's very common in 4e combat), running out of tricks to pull (what tricks? dailies and encounter powers? same issues with vancian magic to some extent, but vancian doesn't get "at will"), being challenging for the DM to run, etc. However, not all of these are exclusively monster issues, and some can be solved by changing things elsewhere in the game. For example, if we used something like the "hit points as a threshold for affecting monsters" mechanic that Mike described for "save or die" spells in a recent Legends & Lore column, we can cut down on some of the challenges solos face because of conditions (but it does add a whole new thing for the overworked DM to track). We're looking at generally increasing the speed of combat overall (from 4e? from 3.5e? what is the baseline they are trying to achieve speed wise?) and finding ways to streamline monsters (Tunnels & Trolls 7.5e shows how to streamline monsters and yet still give them unique powers and abilities) while still making the experience of fighting them exciting, both of which will impact solo monsters, not to mention all other kinds of monsters, too.
As with many, many other things, we're just in the earliest stages of design and testing on this, but here's what we have in mind. When you gain a level, you can choose any class and gain a level in that class, much in the same way that it functioned in 3rd Edition (with Monte behind the wheel of 5e, it's pretty much what i expected). Of course, those of you who play or played 3E know that there can sometimes be issues with this, and if you aren't careful you can build a character that struggles with effectiveness at higher levels. However, there's a lot of good that comes out of this system, including organic character growth, expansive character building options without the need for large swathes of material, and the ability to express your character's specialties through a unique mix of classes.
While there are certainly challenges with this system, a few other changes in the game make it more viable in the next iteration. As I mentioned last week, we're looking at a bounded accuracy system where accuracy (of everything, from attacks to spells) does not automatically go up with level (going back to the Lie of THAC0 - THAC0 increases in proportion to AC increases means you are just treading water. I assume this also means that Acs won't be changing much as one levels in 5e). The discrepancies in base attack bonus between classes in 3E made some multiclassing combinations more difficult to pull off; absent those discrepancies, with the right ability score mix, the fighter and wizard classes mix together without that difficulty. Another thing we're looking at is the way we word certain abilities, making sure that disparate classes work well together. For example, instead of the fighter having to spend a single action to make multiple attacks, we might say that the extra attacks that the fighter gains as he gains levels are effectively free actions that the fighter takes on his turn. Thus, if my fighter/wizard picked up an extra attack through his levels of fighter, he might be able to cast a spell as his main action and then still get his extra attack, giving him the benefit of all of his class levels. (interesting, but I foresee game balance issues)
While this isn't the complete list of all the things we need to do to help make multiclassing flexible and easy, it's an example of the kinds of things we're looking at doing because of what we've learned from the good things and the challenges of previous versions of the game. And, of course, it may turn out to be just one option among several for how multiclassing works in the next version of the game.
Right now, the design of the game does not assume by default that you are using a battlemat and miniatures when adjudicating combat (now this is damn good news which I've heard before but just like to hear repeated), and as such we feel confident that spells like cone of cold could be cones, and lightning bolt could be a line, without having too many problems. However, when we present the rules for using a grid for combat, we're going to want to present ways to convert those spells into the more grid-friendly areas like bursts and blasts (why can't a "cone" be a "cone" template? why can't a "lightning bolt" be a "lightning bolt " template?). We can also present the grid-based versions of bursts, cones, lines, etc. found in the 3.5 Edition of the game (see, why did they have to talk about converting when they already have what they need? sigh). Moreover, we don't even have to limit ourselves to a square grid, and could present the rules for playing on a hex grid too, allowing each group to determine what fits their needs best. (why does the template have to fit the grid? real life doesn't fit s grid.)