Each time you create a custom  view it generates a new .aspx page  that is stored
in the list  folder. I just created a custom list and then created a view  in the
UI. That view shows as an aspx page that was created in the list folder when
I'm in SharePoint Designer. Each custom view gets its own aspx page.

I have the opposite problem. I see links to pages in the UI list  view drop-down
that I do not know how got there. (Horrible English) I did not "create" any
views for these. There are no aspx files in SPD correcponsing to these views.

What links are you seeing, and was the list  created from a custom  list or from
some other type? There are some lists, like a calendar that I think have some
built-in views  that aren't actually files.

It is a custom list  built using a content type. The content type is used on
20-30 sites, increasing at ~10 per year. We used a content type so we could
change columns  everywhere from "one" spot. Additionally, this list has 2 custom
edit forms.

The views  I am seeing have the name of the list, but the content seems to be a
custom aspx page  I created which has only a message  and javascript to shut the
browser. As an aside, I cannot find these pages on my site  anymore. They used to
be right at the site root.

How is this for a guess: when we changed content type 1-2 months ago, the
changes did not propagate to the custom  edit forms  (the GUIDs didn't update) and
somehow this screwed up the views?

I just posted a word doc containing 2 images of the two conflicting list  views.
Its name is screens_FinList_views_091014.

Very likely. Was the content type built  in the browser or deployed as a
feature? If as a feature then doing an update to that can't be done just by
upgrading the feature.

The content was built  with brower. There are WFs on these custom  edit forms  too.
We use this site  as a template to build new sites, and for old sites, we trusted
that the new content type would get "pushed out."

So what is the correct way to make changes to custom list  columns, custom edit
forms, and WFs on the whole mess, so that things propagate throughout a site
collection when changes are needed?

We thought that 1) templatizing a site (with content), and 2) content types at
the site collection level would solve this. Apparently not or are we seeing
bugs.

This will be a long answer and I need to ask another question first. First the
questions

1) Are you using the site  template in the same site collection where it was
built or have you moved it or loaded it to the farm level using STSADM?

2) Are the WFs you are using built  from the OOB WFs, custom  visual studio or
SPD?

Here's why those questions matter.

1) Content Types built in the browser are created with a unique GUID in the
Content Type gallery. If you build an identical content type in another site
collection it will have a different GUID and therefore won't be recognized as
identical.

2) Saving a site as a template only saves the things that are built inside that
site, not Content Types built at the top level site of the site collection. If
you try to use them in a different site collection you won't get all the same
content types.

3) SPD workflows are saved as part of a Site Template, but since they rely
heavily on GUIDs they may or may not function in a site built from the Template.
Thorough testing is required.

4) Changes made to content types deployed as Features can't be updated by
updating the Feature. A custom application needs to be written to update them
using the object model. Content Types built in the UI are more forgiving, but
still not perfect, especially when it comes to views  and document templates.
You should treat content types like a record schema in a database. Changes
should be avoided whenever possible.

In answer to the question "what is the correct way to make changes to custom
list columns, custom edit  forms, and WFs". The only real answer is Plan right
up front and don't make changes. Changes to these elements don't propagate.
Custom programming is usually the only solution.

1) the site  template that we build (with content) is only used in the same site
collection.
2) WFs are all built  with only SPD. We do not use any OOBs.

Per your point #3, the WFs to manipulate the custom  edit forms  seem to be OK
except for permissions when we stamp out a new site. These have to be -re-set
manually with each "stamp out."

The permissions setup would be expected since site  templates assume inherited
permissions and never store customized permissions, users, or groups in the
template. Since the views  are associated with the content type I suspect they
aren't being copied correctly as part of the template process.

I don't know if this helps, but I believe I have seen this kind of behaviour
when I added a list  view web part to a page  in SharePoint Designer. Even though
the page was not stored within the list, that page seemed to get registered as a
view in the list properties, and showed up in the views  drop down for the list.
Is it possible that at some point a list view  web part was added to that "forced
user exit" custom  page then removed again? Or maybe that page was originally
created by copying a page that had a view of the list?