I was going through some code today and had to google some VB 6 related items. Both wikipedia and one of Jeff Atwood's old postings have links to a petition to plead with Microsoft to keep legacy VB alive and well. Needless to say, in hindsight, it failed. One thing occurred to me, though: legacy VB would make a perfect candidate for open source cloning. It would be comparatively simple (both the language and syntax). Unlike Samba, Wine, or Mono it would not be trying to hit a moving target as Microsoft is no longer actively developing it. With a COM Bridge and a reimplementation of forms (probably through GTK, Qt, or wxWidgets) legacy code could be made operational and most code, that which does not actively use COM, could be almost automatically cross-platform. Moreover, those business with a vested interest in legacy VB, i.e. those with a pile of legacy code, would still be able to use it and depend on it and those disenfranchised VB6 programmers would be able to use their favorite language for life.
But it will never happen. The reason is quite simple. The people who actually mourn the loss of Visual Basic are not the ones, as a rule, who will be able or willing to write a compiler for it. This is not to say that there haven't been a few open source imitators or derivations from it. Gambas, for example, is VB-like, but it is no VB clone. There are, I am sure, others who have done work heavily influenced by Visual Basic--but no actual clones (at least, not any of any real size). The next place to look for a clone (either commercial or open source) would be the companies that have a vested interest in VB, that is, the ones with a huge pile of VB code lying around. Once again, these are not apt to undertake the project for the very reasons that made them choose Visual Basic in the first place. The business case for VB runs something like this: it has a mammoth company (Microsoft) backing it and supporting it, we can get full commercial support from this mammoth company and we know that they will be around for a while (i.e. they won't go bankrupt and leave us high and drie), and programmers for this language are as common as dirt (so we won't have to shell out a fortune to some obscure consultant after our lead developer quits). In short, it is a safe pick. Obviously, none of these reasons (I pass no judgment on whether or not they are well founded, only that they are the reasons) are conferred on a project or an odd-ball third party clone (which also runs a pretty high risk of getting sued).
To summarize, the problem is not one of technical difficulty or logistic difficulty (i.e. keeping up with a constant stream of changes), but one of demographics. The very people who would most want this product are the ones least likely to carry out the work. Atwood points out in his article above that most VB developers are moving into C#. I think this is true. VB.NET is probably not the future of the .NET platform. Indeed, it has been a fairly second rate citizen in the .NET world. Read or skim through the ECMA document on the CLI environment. It is clearly modeled after C#, itself modeled after Java, not VB. To all appearances, VB.NET exists largely to ease legacy VB users and apps into C# and the .NET future--at least, that's the strategy. As for how it plays out, only time will tell.