Similarly, watch Vray closely. I have a feeling that in the next few years, Corona is going to eat Vray's lunch much in the same way that Arnold is eating PRMan's right now.
It's great that there's so much competition and so many renderers out there at the moment. This is partly due to the fact that it's not that difficult to write a "close to production" raytracer (ignoring asset paging, recursive procedural and curve support, which is where the big boys really shine).
Ignoring geometry and texture paging, curve support and volumetrics (all of which I'm slowly working on), it could be used in production.
But then I guess any renderer can produce a pretty picture with physically-based shading - but speed-wise (it's a brute force GI renderer only, no irradiance caching) it's competitive with the other CPU renders out there with similar settings. The harder stuff is memory-efficiency - Arnold's amazing at this, and numeric stability over all different types of data.
Given the amount of research out there, it's really not that difficult - most of the hard stuff I found was decoupling the GUI (I've written my own context-creation / scene editor as well which hosts the renderer) from the renderer - that involved a lot of re-writes...
I wouldn't say adding features increases complexity exponentially - I guess it depends on the design of the system, but that hasn't been my experience with my stuff...
I assume by "different sampling types..." you mean BSDF importance sampling for outgoing direction and sampling the Solid Angle or pdf of taking that direction? If so, I'm not sure I'd call that especially difficult...
Building up ready-to-go materials (certainly as many as Vray ships with) undoubtedly takes time, but in the VFX industry, generally everyone writes their own shaders anyway...
Anyway, my focus is on VFX so I can concentrate on those type of issues, whereas I guess Vray needs to work well across different domains as well (product design, archviz, etc) - that'd be where things start getting difficult to balance out the different requirements I'd assume:
e.g. you can save quite a bit of memory by not storing vertex normals as vec3 floats, but as two 16-bit ushort numbers which can then be mapped via a LUT to the spherical coords of the normal. This is acceptable for VFX, and even in worst-case situations (very zoomed in on a very dense mesh with lots of crinkly displacement), it's barely noticeable, but for archviz people rendering at 10k x 10k, they might spot the issues at that size...