It might be interesting to know a little more about this.
The crop mode feature works by changing CMOS registers (a register is simply a memory address that we can set to some value and that value will control some aspect of some external piece of hardware, for example an LED). Normally this is a very simple thing to do in an embedded system. Just set the memory address to the value you want (1 line of C code, or a simple command or two in assembly). However, in our situation, we (ML code) are fighting with Canon firmware. Canon firmware is constantly re-configuring and overwriting all kinds of registers. Therefore, to get the value we want into the register (and get it to stay there and not be overwritten), we have to modify the behavior of Canon firmware. We refer to this behavior modification as 'patching'. It can be very tricky to get right, because we don't want to actually permanently modify the Canon firmware in ROM (that would be very dangerous). So instead, we exploit some hardware known as a "cache" and use it in a way it was not really intended to be used, that is, to fake the CPU into thinking it's reading from Canon firmware ROM, when in reality it's reading from some value we control.
For a long time even before this particular feature was implemented, a1ex had been working on a nice new "backend" for applying and managing our patches that would be easier to use and monitor, and it would be "safer" and more efficient. (There may be situations where we only need to patch something that is in RAM not ROM, e.g. dual ISO, which is much easier b/c we can do it directly without worrying about permanently overwriting anything, but the new backend will handle both for us nicely in a unified way). Like the memory backend, or raw backend, this is one of those "under the hood" features that most users aren't aware of exists, but consumes probably a majority of development effort, and on which many important "user-facing" features actually depend on. These "backends" basically encapsulate the knowledge we learn from reverse engineering and how to get Canon firmware to do what we want, and present an nice, easy to use API to the developer. They are the foundation on which the rest of ML is built.
Since the crop mode feature needs to be able to override registers (and do so very fast and efficiently), it was built upon the new patch manager backend. However, the patch manager itself isn't quite ready for prime time (at least not on all cameras, for example on 60D it doesn't work at all). There are many other things that ML does that require patching Canon firmware, even the extremely complicated process of booting up.
TLDR:
This is a relatively small and simple feature by itself, but it depends on a large change to the foundation of ML. It's the foundation change that is holding it back.
Once the new patch manager is completed and confirmed to be working well (which is very important in this case, since it's at such a low level, and has the potential to effect so many things) it will be merged, and features like this one, and other similar ones in the pipe, will be trivial to complete and merge.
