Short answer: Your ideas are definitely solid, we’re working towards them. Detailed answer continues below.
Give yourself some credit - the UI for blueprints is complicated to begin with, and for interactive merge there’s basically 3x more stuff going on. Not fun
This is a tough one - here’s a really technical response. The Blueprint Editor needs to be loaded in order for a program to present a useful representation of a blueprint, and the blueprint editor (UE4Editor-Kismet.dll) currently depends on the ‘main’ relatively monolithic editor libraries (UE4Editor-UnrealEd.dll). This dependency represents a lot of features, and refactoring features is time consuming and risky.
We’re experimenting with starting the editor command line parameters so that the diff or merge operation is automatically started. Initial feedback is positive. By sidestepping the dependency issue we get to focus purely on editor start times, which would improve a lot of workflows, rather than just blueprint specific workflows. Notably, in P4V this works quite well. It’s easy to use the unreal editor (with command line parameters) as a diff tool and/or merge tool that can be started from the P4V context menus.
Automatic merging of changes that don’t represent a semantic conflict is also on my backlog, I’ll look into getting the priority bumped up. I’ll consider my work on blueprint merging a success if we can automatically bring changes together so that users are focused on getting things done, rather than sorting out conflicts