The only PITA in using package references is recreating your incoming and outgoing bridge definitions as Interface operations or signals. This is the part that I think could be automated.
Components aren’t really part of the model compiler domain. The model compiler is still working on a single domain at a time. In a multi-domain build, you could have multiple instances of the model compiler running in parallel. (NOTE: This might be more theoretical than how BridgePoint actually works right now. I’m going to be lazy and not look it up.) Combining the domains is a linker step. In eclipse (and most IDEs), a project build runs many different tools, so it looks seamless.
The component interfaces give you a place to put implementation specific code in your system model for a specific platform. Thus Dennis’ servo example could use some distribution middleware interface to remote servers on one platform and direct hardware port I/O calls on another. In the old BridgePoint EE skeleton generation paradigm, it was much harder to maintain this kind of reuse of the application domain. Even without different platform targets, test code in component interfaces is easier than test code in EE bridges.
This convenience outweighs the overhead of components in BridgePoint, but that doesn’t mean we shouldn’t be able to modify the tool to eliminate the overhead.