I've looked into a couple of cross-platform options for GUI development and I have decided that Mono would work the best given the knowledge I have. If you look here, under the WIndows.Forms section, it appears that most applications are supported, as long as any platform specific calls are avoided.
The main problem with nodes is that scenario writers are limited in what they can do by what the application developer has determined they can do. Surely there have been times that you are writing a scenario and wished there was a special node that checked for party size, or if a certain type of pc is present, or even just wanted to do something multiple times in a loop. With scripts, scenario writers wouldn't be limited in what they can do. While nodes would work, it is unreasonable to define thousands of nodes to handle any reasonable action or event.
While scripts may be harder to learn at first, there are things that can be done to help the transition. Imagine a toolbox of code snippets, each matching existing functionality in BoE, that can be dragged and dropped onto an event handler. The code snippets would lower the barrier to writing scenarios, and people would learn the scripting language (Javascript) over time.
I envision two types of BoE applications: the first would be the 'classic' version of the game. This would include the scenario editor, party editor, and game itself. The interface would be similar to the existing interface, at least for the game, and all keyboard bindings and mouse events would work the same. Using Mono, one version could be written that works the same on all development platforms (Windows, Mac, Linux). This version would mainly be for scenario writers or people who enjoy the classic version of the game.
The second type of BoE application would be the 'modern' version. This type of application would be platform specific. For instance, one version would be written for Windows 8, another for iOS, another for Android, etc. This 'modern' version would only include the game itself (and possibly the party editor) and would add touch support. Instead of (or perhaps in addition to) keyboard bindings, certain actions would be presented as buttons only. This version would mainly be for a new audience, or people who want to play on devices besides their desktop computer.
Initially I thought that the conversion from old scenario format to new format should be done on the fly, so that you could just pick your favorite scenario and start playing it in the new format. I think this idea may be a mistake, however. Rather than automatic, scenario writers should have to import their existing scenarios into the new scenario editor, checking for errors, and allowing them to be tested before they are played by the average user.
I'm still mulling this idea over, but since this project is open source and would likely be hosted on Github or another online repository, we could have some sort of directory containing scenarios that have been converted and tested by users. A single location for scenarios we know to be playable in the new format.