The source citation system at Ancestry.com which the OP has used does not support templates. There is a date field under the source and a date field under the citation. This isn't an accidentally redundant design. It gives users the ability to reuse the same source over and over again where the difference is only in the date of publication. The same applies to the detail field. What isn't put in the source field (i.e., year of census, county of census, etc.) can be put into the detail field. This makes things more flexible, something needed for Ancestry.com's one-size-fits-all approach.
Consider the following two examples:
A = Source: Newspaper XX;
Citation Detail: Vol XX Issue XX Sec XX Pg XX
Citation Text: John Smith died...
B = Source: Newspaper XX Vol XX Issue XX;
Citation Detail: Sec XX Pg XX.
Citation Text: John Smith died...
Is A=B? Is A≠B? Is A conceptually flawed?
I argue A=B because they contain the same information. I don't invalidate the source by including the volume and issue info. in the detail field. It's not going into the text field, which is for what I'm citing, so it's not confusing the source for the citation, as you implied, and therefore not conceptually flawed. It's just including more locator information in a detail field that already contains locator information.
Furthermore, regardless of how this information is entered by a user or stored by FTM, the only place where "form" comes into it is in the output. As long as what FTM/Ancestry.com outputs is reasonably close to the community's standards, then how it's entered or stored simply doesn't factor in. (It's only relevant when we discuss workarounds to shortcomings.)
Okay, let's get back to the OP's dilemma. He has used Ancestry.com as it was designed, and let's assume that he purchased FTM 2012 in response to the pitch that it gives you the ability to have your Ancestry.com tree on-the-go. In his case, however, he has to create (potentially) 4,000 new sources before he'll really have his tree on-the-go.
I say that's BS. First, FTM 2012 ought to deliver what it promises, or it ought to have a long list of exceptions in its marketing materials. That means having your tree on-the-go, not most parts of it. Second, genealogy software should help you stay organized and save you time. This would all be easier if FTM offered some abilities to reuse and modify sources along with more abilities for viewing stuff in the Sources workspace.
For example, instead of having to distinguish the "Iowa State Census Collection" by using the detail field, we would all benefit from having the information parsed and sort-able:
Iowa State Census
Date of Census
Location of Census
Household
(This is only possible by either recreating each source or by conscientious use of the detail field, which can only be sorted by its first character.)
A second example. I should be able to view all citations from a particular newspaper (without some repository or other trickery):
Newspaper XX
Volume XX
Issue XX
Section XX
Page XX
In this case, if individual sources are created for each volume+issue, users are potentially dealing with a huge quantity of sources without the ability in FTM to logically group them (e.g., by newspaper drilled down to volume drilled down to issue, etc.). This is more about working around a shortcoming in software than doing what's ideal.
Yes, in what I've discussed, the source can't stand alone. So what? It isn't meant to. It's mutually dependent on the citation. (Besides, my proposal is that FTM/Ancestry.com's system be modified to separate publications from sources/authors and to make them reusable.)
Yes, this doesn't conform to GEDCOM's structure of SOUR PAGE TEXT. Big deal. There are other equally valid ways to parse the data, and regardless of how the information is input or stored, it can always be spit out, for electronic exchange, according to the GEDCOM standard...and, where printing or the equivalent is concerned, according to the MLA/Mills standard. That's all that matters. Everything else is about efficiency.
Consider the following two examples:
A = Source: Newspaper XX;
Citation Detail: Vol XX Issue XX Sec XX Pg XX
Citation Text: John Smith died...
B = Source: Newspaper XX Vol XX Issue XX;
Citation Detail: Sec XX Pg XX.
Citation Text: John Smith died...
Is A=B? Is A≠B? Is A conceptually flawed?
I argue A=B because they contain the same information. I don't invalidate the source by including the volume and issue info. in the detail field. It's not going into the text field, which is for what I'm citing, so it's not confusing the source for the citation, as you implied, and therefore not conceptually flawed. It's just including more locator information in a detail field that already contains locator information.
Furthermore, regardless of how this information is entered by a user or stored by FTM, the only place where "form" comes into it is in the output. As long as what FTM/Ancestry.com outputs is reasonably close to the community's standards, then how it's entered or stored simply doesn't factor in. (It's only relevant when we discuss workarounds to shortcomings.)
Okay, let's get back to the OP's dilemma. He has used Ancestry.com as it was designed, and let's assume that he purchased FTM 2012 in response to the pitch that it gives you the ability to have your Ancestry.com tree on-the-go. In his case, however, he has to create (potentially) 4,000 new sources before he'll really have his tree on-the-go.
I say that's BS. First, FTM 2012 ought to deliver what it promises, or it ought to have a long list of exceptions in its marketing materials. That means having your tree on-the-go, not most parts of it. Second, genealogy software should help you stay organized and save you time. This would all be easier if FTM offered some abilities to reuse and modify sources along with more abilities for viewing stuff in the Sources workspace.
For example, instead of having to distinguish the "Iowa State Census Collection" by using the detail field, we would all benefit from having the information parsed and sort-able:
Iowa State Census
Date of Census
Location of Census
Household
(This is only possible by either recreating each source or by conscientious use of the detail field, which can only be sorted by its first character.)
A second example. I should be able to view all citations from a particular newspaper (without some repository or other trickery):
Newspaper XX
Volume XX
Issue XX
Section XX
Page XX
In this case, if individual sources are created for each volume+issue, users are potentially dealing with a huge quantity of sources without the ability in FTM to logically group them (e.g., by newspaper drilled down to volume drilled down to issue, etc.). This is more about working around a shortcoming in software than doing what's ideal.
Yes, in what I've discussed, the source can't stand alone. So what? It isn't meant to. It's mutually dependent on the citation. (Besides, my proposal is that FTM/Ancestry.com's system be modified to separate publications from sources/authors and to make them reusable.)
Yes, this doesn't conform to GEDCOM's structure of SOUR PAGE TEXT. Big deal. There are other equally valid ways to parse the data, and regardless of how the information is input or stored, it can always be spit out, for electronic exchange, according to the GEDCOM standard...and, where printing or the equivalent is concerned, according to the MLA/Mills standard. That's all that matters. Everything else is about efficiency.