Would you be happy to move out of org.fxmisc and more closely integrate with scenic view, perhaps by placing the code in a package like org.scenicview.view.cssfx or org.scenicview.view.tabs.cssfx? This simplifies the package hierarchy somewhat (because very soon I'm likely to remove the org.fxconnector package and move that under org.scenicview (because I don't want to keep paying for fxconnector.org domain name) :-)
Jonathan, I refactored cssfx stuff to move it under org.scenicview.extensions.cssfx.
The idea behind is to introduce some convention for ScenicView to receive more additions/plugins in the future.
This could turn into:
org.scenicview.extensions.EXTNAME.module : contains the stuff that will be used remotely in injected applications
org.scenicview.extensions.EXTNAME.ui : contains the related stuff that will be used in ScenicView app to enrich the base ui (new tab, new menu, ...).
I think ScenicView would benefit also in some refactoring in order to restructure a little bit the app so that additions become less intrusive and easy to plug (use observable, API for ui plugins, command pattern for remote controlling, ...).
If you agree I'd open an issue so that we can expose and discuss such ideas.
Sorry, I've been super busy over the weekend and run out of time to look at this.
Regarding the functional interfaces - I still think that there is no need for the duplicates in this pull request. The argument for readability is not a strong one - no one will be using these APIs other than us developers, and even then, we've done exactly the same thing in JavaFX - we use the generic Java 8 interfaces wherever possible, rather than custom interfaces for each use case.