Hmm... my read is that this collision check wasn't a first pass, but rather a just-in-case second pass necessitated by allowing foo.jpg and foo.flv to coexist in the first place.

The save function has three cases: new item, update item, or insignificantly update item (where almost nothing happens).  This code is/was in the new item part, and comes after _change_name_or_slug_on_conflict is called (new line 366).

In the old version, _change_name_or_slug_on_conflict disallows identical filenames, but allows foo.jpg, foo.png, and foo.flv to pass (provided that, by chance, their slugs were all set differently, which seems rare in practice given how uploader and server_add typically work).  Then, before copying the data files, it runs this code to catch and correct the conflict between foo.flv and foo.jpg with their thumbnails.

In the new version, _change_name_or_slug_on_conflict disallows filenames with the same base, so foo.jpg, foo.png, and foo.flv wouldn't pass in the first place.  Since this is no longer a possibility, this second check is unnecessary.

In both versions, _change_name_or_slug_on_conflict is also called in the update item part of the save function.  I didn't think about this until just now, but it's possible that the old version could lead to a conflict here since the secondary checking only happens for new items.  Example: create foo.jpg, create bar.flv, then rename bar.flv to foo.flv (while maintaining its slug).  I haven't entirely worked through this, but it seems that this could be a problem with the old version, no?  In any case, the new version would protect against this since foo.jpg and foo.flv can't coexist.

One other note: this change should be entirely safe with existing databases.  If existing items are already coexisting without conflict (coexisting without conflict - worst hippie commune name ever), they'll continue to do so and this will only a) change their name/slug if they're already being otherwise updated or b) change the name/slug of new items being added.  So, we don't necessarily *need* to do a DB update... but perhaps we should anyway?