Does it work well in the "don't want any default" case?
It does the same thing as completing-read-default, which is that it allows you to enter an empty string by pressing RET and assumes that the calling function is expecting that to happen. In particular, this means that any code that wrongly assumed that setting REQUIRE-MATCH would guarantee returning an element of COLLECTION is now equally broken in both standard completion and ido completion, as opposed to being spuriously "fixed" by ido ignoring the spec of completing-read.
'prepend-empty-string' sounds like what I'd expect;
'append-empty-string' doesn't sounds particularly useful (what's the
goal here?); 'Any other value' kind of looks like over-engineering.
I wasn't sure if any of those made sense other than prepend-empty-string and nil, but they were 2 lines of code each, and I can remove them later (I haven't made a release for this yet). The idea behind append-empty-string was that you might to make it possible to return the empty string even though REQUIRE-MATCH is non-nil, but you don't want it to be the default. The function thing was just "I dunno, maybe someone needs someone else." I'll probably remove them if I don't find a use for them. They're not used at the moment.
Anyway, I'm finding it to work pretty well without requiring a distinction between commands that do or do not expect the empty string. I merged that branch into my bleeding-edge branch and fixed a bunch of bugs, and I'm going to test it for a while before releasing.