I like the concept of Jabaco, I like it a lot. It's exactly the right way of giving backwards compatibility and platform independence.
However, I have some minor comments. Please, don't take them as criticism, just some random thoughts about how to best handle such a concept.
* For it to be practical when you have an established code base, it needs to be almost 100% compatible with VB. If you need to correct something every tenth line, or even every hundredth line, it's usually too much work and too many bugs go unnoticed for it to be worth it, and a dump and rewrite is preferable.
* Almost no real world program is pure VB. Most commonly, databases are used, but also various other components, which you may or may not have the source for. Sure, one could rewrite some of them, something like a calendar control can be quickly rewritten, but how long does it take to rewrite at component which displays maps in a format you don't know? In other words, some way of using these binary components would be nice.
* API calls. You'll find very few VB6 programs that does not call the Windows API. Of course, this is not possible in a platform independent world, but when yoy look closely, it's usually only a few API's that are typically used. Perhaps these could be intercepted and replaced with platform independent code (and, of course, a more modern object model encapsulation as an alternative).
* IDE. We already have a working IDE for VB which is quite capable. Sure, it would be nice to have an alternative, but it's not critical at the moment. It would be more beneficial for the project to focus on the compiler, in order to make it more powerful and more compatible with VB. Then, eventually, a new IDE can be given priority.
* Then, once we have reached that far, it becomes meaningful to extend the language, while still keeping the ability to compile "standard" VB programs. Extend, rather than replace. For example, 64 bit integers could be added (face it, 32 bit integers are way too small when we have TB-sized disks), methods could be added, more advanced OO stuff could be added.
Once again, don't take this as criticism, just as some helpful thoughts from my experience with VB and my needs for a tool to replace it.

Quoted

I'm working on it. Which parts are not compatible with your project?

To be quite honest, I've only made preliminary tests yet, so I wouldn't go too far in analyzing the results.
Some things that didn't work without fixing:
* API calls
* Database access
* User controls (even when compiled within the same exe)
* Compiling as a screen sacer. OK, not very common use, but it was one of the cases I tried.
There were some smaller issues as well, I think I found some missing properties, but I don't remember it clearly.

Quoted

ActiveX-support is difficult. Let me know if you find a good COM-library for Java.

Yes, I know it's difficult. Actually, I have no idea how to do it, especially platform independent. I know it would be a very important step, though.

Quoted

This could be a solution. Would be cool if you start writing a tutorial for API-replacement.

I don't think a tutorial would be useful, as each API is very different.
Basically, what I see is the compiler intercepting the call and re-routing it to some code in a runtime library (or compiled into the program) which performs more or less the same thing.
As I said earlier, not the entire Windows API needs to be replicated, I think that maybe 50 API's would take care of 99% of the used API calls, and most of them are quite simple.

Quoted

Troberg, platform independant ActiveX is not realistically possible.

I'm well aware of that. It would be a huge plus, as VB without ActiveX libraries is a pretty empty box, but I also realize that good does not equal possible.
To be quite honest, I don't know how it could be done. The closestway I can think of would be some kind of dynarec, ie recompiling it at run time. The recompiling is fairly straightforward, but chances are that the ActiveX library does a lot of platform dependent stuff as well, which will be hard to fix. It would make the binary runnable on the target hardware, but there is no guarantee that it would fit the target OS.
Now, I'm not saying that it should be done, I'm just brainstorming in the hope that it might start some thought process that ends with some innovative ideas.

Quoted

I think the real benefit to Jacabo is that it is mostly VB 6 compatible (language wise) so the learning curve is not as steep as it might be for other languages, plus, its output is cross platform.

For me, it's that I have some ten million lines of VB code which I wish to bring with me as I switch to Linux. As no one else will help me convert or bug fix it, the better the compatibility the better. For instance, most of it relies heavily on databases, and I do not want to rewrite all database handling.

Quoted

As far as API calls, it would probably be worth while to write a module that wraps all the API calls you commonly use. If there are only 50 that shouldn't take too long. It will make your application Windows dependant, though.

Actually, the smart thing is to make replacements rather than wrappers. If need be, these replacements could call platform specific API's, but should do it in an intelligent way so that it behaves differently depending on the platform. For instance, say that I use the API for handing the registry. In Windows, the replacement would call the Windows API, in Linux, it would contain code which writes to a config file.
Most of the API's used, at least the ones I use, are fairly simple, such as Read/WritePrivateProfileString, SetParent, SetCapture, BitBlit. They usually map more or less directly to java equivalents, so capturing the calls and remapping them to replacements would not be a huge deal.
Once again, only brainstorming here. I see my ten million lines of code and would prefer as little rewriting as possible and as few odd bugs as possible. Even 1% better means 100 000 less lines to fix...