Also shining a light to the GUI side, how about combine Opal (CoreGraphics) and Back? Implement GUI using CoreGraphics functions as Apple did, and handle the backend issue with CoreGraphics.
Yes.
While not fusing, I'll be working on Opal-based backend. It is intended that -back will set the appropriate Core Graphics context before dropping into -drawRect:.
Alternatively, we can choose to implement Opal on top of CoreAnimation, then in turn on top of OpenGL (and let the OS handle how to get OpenGL work), and then GUI on top of Opal, deprecating Back totally.
No.
Core Animation does layers, and it does layers only. Layer content still needs to be provided. In most cases, it is provided by Core Graphics, which in our case means Opal. Sometimes, it might be provided by NSImage or CGImage. It still needs to be provided.
In any case, layers are rectangular and by themselves have no content. They might have a background color, but as Opal (and Core Graphics as an API) handles drawing 2D bitmap content -- lines, curves, images -- you can't implement Opal using Core Animation.
This will require promoting CoreBase and Opal into Core package, merging them with existing packages Base and Back. It will deprecate all current Back API in favor of CoreGraphics API. Also, it will change the dependency order: GUI -> Back+Opal -> Base+CoreBase.
Regarding back+opal, I disagree this should be done, especially in the short term. Long term, if Opal turns out to work fine, perhaps we could bring down the number of backends to one (Opal), as surely some ported apps will start depending on having Opal as the backend. What is certain is that all apps that want to use Core Animation integration into AppKit will depend on having Opal as the backend.
Regarding mixing Base and CoreBase? I can't comment on that one, as I'm not intrinsically familiar with either of these codebases :-)