So looking at my reply again now, I pretty much stand by it but could word it a lot better. In essence there are two routes which I personally believe are the way forward. The former is very reliable but inflexible (would have to be targeted at specific machine configurations, great for OEMs), the latter more modern and configurable, as we know, EMC2 can be applied to so many real time control problems.
My personal choice would be the latter although I do love FPGAs and processing in hardware, makes you feel like a real (nerdy) man.

As for the first solution...
Replicating EMC2's efforts would be a waste of time. You want to retain as much of it as possible. You do however, want to dispense with the real time aspects as much as possible to remove uncertainty in the performance of your controller. While EMC2 is pretty fantastic, there are always doubts over how the hardware will behave in scenarios it was never designed to be used in, i.e. hard real time.
Reusing EMC2 for non-real time stuff however means you have a pretty front end, that can process G-Code, present (non-real time) buttons to users, blah blah. You have all the configuration and connectivity of Linux at your disposal.
This front end would convert the G-Code into low level codes that a real-time machine controller can understand. You would essentially send the real-time controller a list of co-ordinates, speed and torque vectors to a FIFO queue which are to be processed at a fixed clock rate. With large amounts of RAM available these days you would easily buffer huge amounts of data to the controller in a non-real time fashion from the front end, which is then read and unloaded in a real-time fashion by the back end. Any front end lock ups however would stall the queue. As I said, with large amounts of RAM these days, you would be pretty confident that you have a sufficiently large queue for even large machine programs that the whole program could be buffered before starting.

A note on the above; the benefit is you don't even need to use double float data. You can speak to the controller purely in encoder counts. This gives you the control over unit conversion etc on the front end while the back end does what it does best, processing data in a real-time fashion making you pretty parts, or whatever your machine may do.

As for the second solution...
The inflexibility (compared to EMC2 anyway) of the former FPGA option would mean configuration would have to be done at too much a low level for most users. The most obvious option is to develop a purpose built hardware platform (embedded PC) for EMC2 to run in real-time mode. You can do away with Intel power management lock up issues, commercial graphics cards etc. This way you have a trusted solid, small and power efficient platform. This is essentially what Beckhoff and others do. I use Beckhoff PC based stuff at work and it works very well.
This method means you retain 99% of EMC2. You would need to port it to the hardware platform and ensure it works well but this is trivial compared to the aforementioned. Linux also supports a large hardware base already so you hit the ground running.

Networking
In regards to networking, or course Linux has many options here, so presenting a web interface that ANY computer could connect to would not be an issue, although I would sway toward just having it share a network path for dropping files in. You could in theory write connectors from your favourite CAM program to send it over a TCP connection. Possibilities are endless, blah blah, {insert propaganda speech}.

"I don't want to run my machine from a PC"
In reality, all solutions in the end are some form of computer processing. Just because it is actually running on a computer marketed as a personal computer does not mean it is any lesser. In fact some have probably found their PC with EMC2 or any other controller to be far more reliable than their commercial units.

Where can FPGAs fit into all of this?
Function specific, real-time modules. Servo drives, digital I/O, analogue I/O, encoder readers, serial ports, blah blah. Check out the Beckhoff catalogue for ideas.
Talk to these modules in real-time from a real-time master (EMC2). If we could develop an open source VHDL/Verilog EtherCAT slave module, that would open up worlds of possibilities for DIY CNCers.
Imagine you could buy a $100 brushless servo drive? Sure it doesn't have the option for positional control, some ad-hoc ladder logic implementation etc, but why would you want it anyway? Every time I use a drive for machine control I don't use any of that stuff. I put my servo drive in velocity or torque mode and put it in the PID loop of my CNC controller. Therefore I have all this functionality in my device sitting there dormant.
I would propose an open source EtherCAT torque-mode servo drive which has it's velocity and/or positional loop closed by EMC2.
Digital I/O, analog and all those other goodies can be implemented in much the same manner.
EMC2 just needs a good configurable EtherCAT master imlpementation and the community needs a good EtherCAT slave implement in VHDL/Verilog.

In closing
TGIF!