As long as they are valid IDs I don't think they need to match. When
working with lists you should never depend on KNOWING what the list  ID
is without checking for it. For example, If you find some way to
synchronize the instance IDs of the lists in your Dev environment  with
production you may be tempted to simply hard code a call to a list by
using the GUID as a parameter. That is a dangerous thing  to do, because
as you have already seen keeping GUIDs synchronized requires a lot of
extra work. The right way to do this would be to walk the collection of
lists in a site to get the GUID of a particular list and then use the
GUID. That approach  will work on both the production and dev
environment even if the GUIDs are not synchronized.

I agree with what you said, but for our
environment we have an extra tool that work off of the list  ID. The
main one that brought this to our attention is a Parent/Child field
control, a basic dynamic filter choice box. We redeveloped the code
and it updates successfully in the test environment, but only on
those columns that we create in test, not any of preexisting columns
transfered in for production. Perhaps there is something else in the
control code we should reconfigure to reference it based on the GUID,
rather than the actual ID.

That's the point I was trying to make. Even if you successfully
synchronize your test and production environment  you won't have the same
GUIDs if you scale your system by using templates, stsadm Export/Import,
or several other tools. I normally code things to find a particular
list ID based either on the parameters of something available to the
code. For example, you should be able to get the GUID of the list
instance where a field control is being used from the properties of the
field itself. The list  instance is somewhere in the hierarchy of parent
containers for the field.