Hi Jack (and everyone else),
first of all, two thumbs up on your effort to make FPGA development easier. I'd like to throw in my two cents since I think the approach isn't quite getting near an "Arduino for FPGA", which seems to be the goal.
The Arduino has an extemely low barrier to entry, which the Papilio is missing. Some time ago me and some colleagues took an Arduino and built some cool stuff within minutes, despite me having never worked with a microcontroller. Download the IDE, copy&paste an example from the net, run it, modify a few things, run again -- there it is, the first blinking-LED program I built on my own. Everyone was enthusiatic about it.
Contrast that with the up-front effort needed to do the same with an FPGA. I tried to bring an FPGA into the mix the same day, just for fun, and we gave up before we finished installing ISE. Despite me having build a CPU clone in Verilog before, so it was definitely not lack of skill. Despite the Verilog code for a few blinking LEDs is no more complex than doing the same in C. Despite the others being programmers who, even without experience in hardware, would have grasped the way Verilog works easily. It was just the artificial barrier to entry that was too high compared to Arduino: get an ISE license (on some unmaintained legacy licensing site), download ISE (way too big), install ISE (doesn't run on MacOS X), use ISE (I hope the guys who built that got fired).
My take is to start with the premise that the barrier to entry must be as low as for Arduino. That likely means to remove ISE from the loop -- even with a cloud-hosted version, asking people to register on the Xilinx homepage and obtain a license file just for the sake of it is exactly what should NOT happen.
Without ISE, things are obviously getting harder. The most obvious approach would be to build a (large!) series of "batteries included" FPGA configurations, synthesize yourself in ISE (or command-line xst, ngdbuild, par, bitgen), and make them available as bitstream files. Then, just like now, let the user select one of pre-built bitstream files and write software for it. This is not VHDL development, but offering a large number of pre-built FPGA configurations comes closer. Building these from common code can be done in scripted builds.
The next step would be to make large parts of these configurations run-time configurable through (Verilog-defined) programmed registers, BlockRAM contents, etc. This gets even closer to hardware design. Except for the high-performance stuff, most parts don't mind including yet another mux to make the design more flexible.
As a further tool, these "soft" configuration parts can be patched into an existing bitstream. The locations of BlockRAM and LUT contents are well-known enough to do that.
Again, just my opinion.
Greetings,
Martin