Thesis: I believe the IDE and personalities should be broken out into separate SKUs.
Since the Galileo IDE can support multiple languages, it might make more sense to break up the SKUs better. With VS.NET, you buy VS.NET and get VB.NET, C#, and C++ - whether you want them all or not. My thought is that you could have the IDE be sold as the base item. It would contain things like source code integration, StarTeam integration, Caliber/RM integration, Refactoring, and maybe some more core bits. The personalities could then be sold as add-on packages. Delphi would contain Win32 and .NET. The C# personality would be separate from that, as would the C++ personality. Each personality would be sold as Pro, Enterprise, or Architect. The add-on packages would plugin to the main IDE and contain all of the bits that pertain to that personality (e.g. VCL, VCL.NET, debugger, designers, etc.).
While this would be more work initially for Borland, I think the benefits would be huge over the long-run. If someone reports a bug in the IDE that is truly an IDE bug, the IDE can be fixed and a patch released and you would get that fix for all personalities. If there is a bug in a personality, just update the personality. If the fix touches both, then both parts can be updated. This independence would be ideal for the consumer. For example, if there is a bug that is causing IDE performance bottlenecks, the consumer may be forced to wait for an entirely new release of Borland Developer Studio (BDS), since fixing those problems may require breaking changes to the interface compatibility initially released with Delphi 2005. By adopting this model, Borland could start to release more frequent patches, and also dedicate resources to the appropriate codebase based on SKU sales and profitability.
I could also see a tool used in the Borland R&D department where you would have dependancy graphs used to tell the team which files would be affected by a specific change. For example, pretend there is a unit named "CoreIDEServices.pas" that needs a patch. The developer would fix the patch, run the tool, and it would say that the only file that needs to be updated is coreide90.bpl. Perhaps a VCL for Win32 bug fix would result in only the PAS file, DCU file, and corresponding BPL file needing deployment.
People have been asking for the VCL to be more of an "a la carte" model forever. This could be a step in that direction. I'm not advocating that this be done today. Iron out some of the current problems, but keep an eye on this model. I think it would serve everyone well.
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.