You can put the workaround in either place, each has positives and negatives. I suggest you take both approaches.
If you do the workaround int he kernel mmc driver, all Recovery and update-binary executables (even if not recompiled/relinked) will no longer trigger the issue *IF* they are repacked with the new kernel.
However in the case that Samusng didn't place their workaround in the kernel mmc driver, you are then forcing everyone to use a "recompiled" kernel to get the "safe" feature, rather than having the flexibility to use "repacked" stock kernels. Some people prefer "repacked" stock kernels.
If you do the workaround in libext4_utils.a, there are 2 ways you can go about it:
1) just use the pre-existing GB binaries for Recovery and update-binary. This doesn't even need a recompile. This doesn't even need ICS source.
2) put the workaround in the ICS libext4_utils.a. You don't need to make changes in 2-4 places. You just need to make the one change in wipe.c mentioned earlier, then *relink* your existing Recovery and update-binary against the patched libext4_utils.a. There is no need to "fork" Recovery or update-binary, since you just make the change once at the lowest "user-space" level code.
The advantage of the workaround in Recovery and update-binary, is it will work with any kernel (even the existing "unsafe" ones) and you can do it right now, even without needing to access any ICS source code.
You would need to have the people who put together kernel images start using the GB-based Recovery binary and also instruct the people putting together ROM packages to use the GB-based update-binary, the latter is something most ROM developers already do on E4GT, except possibly the AOSP/AOKP folks.
If you opt for the source code change, you are going to fork a file somewhere, either a build make file or some include file in the case of the mmc driver workaround, or a single function in wipe.c. It is no more or less difficult to maintain a fork of the build make file as it is to maintain a fork of wipe.c.
We already know having the workaround in Recovery and update-binary coupled with an "unsafe" kernels that do mmc_erase() works fine as most of us have been running this way since the beginning. We never heard of these EMMC lockup/superbricks in GB and the "workaround" in GB was essentially placed in Recovery and update-binary, because the kernel had MMC_CAP_ERASE enabled.
So why don't you just do both methods? That addresses the most situations and gives the most flexibility in producing "safe" environments.
you are right
and u have pointed out the pros and cons for the 2 approaches clearly
i am pleased with respects (hope i say this correctly)