(2) can probably be addressed with OpenCL -- Altera seems to be working an SDK[1] that allows you to write C code which, as I understand it, would compile to an image that you could then program on to your FPGA (or you could just compile for execution on a processor). So fortunately, no Verilog or VDHL necessary.
(3) is another issue, but I don't think the consumer would necessarily need to worry about compilation. The developer would just include the compiled programming files for different FPGAs in the application.
If you mean that it'll be slow on the developer's side, that's definitely a valid point. I'm sure, however, that you'll see FPGA manufacturers start to move toward remote compilations so that you're not necessarily limited by the hardware you have in-house.
Altera calls it "logiclock," Xilinx has a different term, but the idea is that you don't need to re-synthesize the entire FPGA for every change. In fact, you may not want to. If you are tweaking a certain region, you're usually happier if the place & route doesn't send your stuff through a route that then kicks off a line in another block so that the timings are now off in that other block.
For an FPGA the timing is how you measure performance and getting the best timings can take quite a bit of work. Being able to lock that once you've got it right is a big plus.
It's kind of a mixed bag. It's worked okay for me if changes are truly minor, but if there are large changes to the logic it doesn't seem to be very good about "forgetting" what it learned from the previous pass. Three or four times this week I've had a design fail to make timing with SmartGuide, but work when doing P&R from scratch.
(2) is called High Level Synthesis. While a great idea, and quite practical, it does not lift you from the burden of understanding the FPGA. Generally you have to make your C code fit a very rigid format that compiles to a pipeline or similar - the advantage is that you can test it as C code, not that you take off the shelf code and run it on a FPGA. There would be no point to that - a hard processor will always be faster at running arbitrary C code.
In addition, most of these tools compile to HDL, so they only add to compilation time.
Regarding (3) remote compilations, Altera is lifting off the hardware burdens for developers with remote compilations on cloud. see cloud.altera.com for Altera's tool extension
(3) is another issue, but I don't think the consumer would necessarily need to worry about compilation. The developer would just include the compiled programming files for different FPGAs in the application.
If you mean that it'll be slow on the developer's side, that's definitely a valid point. I'm sure, however, that you'll see FPGA manufacturers start to move toward remote compilations so that you're not necessarily limited by the hardware you have in-house.
[1] http://www.altera.com/products/software/opencl/opencl-index....