Did you make a copy of the original form, then modify the copy? Always a good
idea to keep the original in case the modified one gets schwacked.

I prefer to hide the current form  View Web Part and deploy a Custom Form Web
Part on the same page. It seems to keep me from screwing up too much when I try
to tell SP to use a different file for New/Edit/Disp forms...

Interesting approach. Doesn't keeping and hiding the original FVWP result
in a lot of overhead?

My main problem  with custom  forms tends to be the whole Parameter/Filter
issue, whereby I say "create a parameter called ID and fill it with ID from
the Querystring"... usually when I do that through the GUI, I get an ugly
error in Design mode and end up just hand-coding the param (and sometimes
the filter CAML as well).

Seems like there's too much "fuzzy" involved in this process; I can't wait
to spend some quality time with SPD 2010 so I can plan the appropriate level
of disappointment for the next few years.

I know what you mean in terms of overhead; you get that page "drag" when you
have two heavy List View Web Parts on a page. I don't see that behaviour when
we're talking about forms, perhaps because they are pretty light. I might crack
open Fiddler and take a look-see.

I built the new forms  from scratch. The problem  seems to be that I
originally had these items in a separate list, but the client then decided
they wanted a certain set of functionality that was only available (without
pain) if the items were all in one list. This meant that I had to merge
them into a single list, and point the *second* set of custom  forms to the
first list, modify GUIDs, list  ID/name properties, slightly different field
names, etc.

And yes, if I had known then what I know now, I would have STARTED this way
and built the whole thing with content types made up of site columns. You
never can tell with clients.