...The card does not want to initialize (usually) with my final code, but works fine with other test sketches.
Hmmm...Let's think about it:
1. This card works properly (and consistently) with test sketch(es), right?
2. This card does not work properly with "final code" (whatever that is), right?
My idea is that maybe the "final code" is buggy.
Note that "buggy" doesn't always mean bad instruction sequences; sometimes it means that a program can deplete system resources (or not) depending on the conditions under which it is run.
Unbridled use of Arduino String objects (or anything else that uses dynamic memory allocation) can cause confusing and seemingly intermittent problems that are actually reproducible if we knew exactly what the program was and how it was being tested.
Functions (with a certain amount of local memory) that call other functions (with a certain amount of local memory) can work under some circumstances, but, depending on the sequence in which they are called with different program runs and depending on the depth of functional hierarchical organization and amount of local memory involved, can create "stack overflow" problems that are difficult to pinpoint.
Stuff like that...
Not having seen the "final code," how the heck could we give a meaningful guess? I mean, if it isn't hardware and it isn't software, then maybe it is Something Else.
My suggestion that the "final code" might be buggy is based on the assumption that the final code does not do anything different in the initialization sequence than the test sketches, i.e. doesn't use functions in addition to the code of the test sketches.
By the way, in addition to showing us the final code, you might mention what test sketches you are using (the ones that work for you):
SdFat library examples? Which ones?
arduino-0022 SD library examples? Which ones?