Motivated by the need to understand what was happening in a recent request to re-process data with alternative vertex-finding that included a requirement of using only BTOF-matched tracks, I investigated the state of BTOF-matching in various places. I am documenting this here following the order in which things occur presently in the BFC of physics productions.

1. When Sti finds global tracks, it actually already does BTOF-matching on all tracks [1,2,3], and stores that with the global StEvent/StTrack. This code uses an StDetectorDbChair (St_tofStatusC) for determining TOF cell status.
2. The vertex-finder (PPV) runs, then (when in the UseBTOF4Vtx mode) repeating BTOF-matching on its own [1] for a set of tracks that pass its cuts, and using nearly identical, duplicated code [2,3]. I have uncovered an important difference in these two BTOF-matchers: the one in PPV users coarser granularity in the BTOF, requiring a match only within a tray & module, while the BTOF-matcher for Sti requires a match within tray & module & cell (a factor of 6 finer granularity; please see the figure at the bottom of this page). The impact of this is that Sti does not have all the same matches that PPV has because tracks may miss a BTOF hit by a cell due to finite resolution in the track projection. Another difference is that PPV's BTOF-matching code uses a different accessor to the BTOF status tables that had been broken for the past 5 years, but was recently fixed.
   As for PPV, I confirm again that when in the UseBTOFMatchOnly mode, only tracks that match BTOF hits are used in the vertex-finding. PPV then fills StEvent/StPrimaryVertex with the correct numbers for tracks used and tracks with BTOF hits [4].
3. Sti then extends the global tracks to the primary vertices and labels them as "primary" if they pass certain cuts on proximity to the beam axis and one of the found vertices [1]. This can result in a track being labeled primary when it wasn't used in vertex-fittng, and can also result in a track that was used for vertex-fitting being labeled NOT primary. I haven't looked carefully at this, but I expect that nearly everything used in vertex-finding is labeled as a primary (i.e. Sti's cuts are looser).
4. Sti then creates primary versions of StEvent/StTrack, requiring the aforementioned labeling as primary [1], and copying the global StEvent/StTrack information about whether each track has a BTOF match. After creating the primary tracks, Sti loops over the primary vertices [2] and instructs each vertex to count the number of its daughter tracks that have BTOF matches [3], over-writing the number that was stored there by PPV. Because this determination of BTOF-matching is more strict than PPV's, it generally results in a reduction of the number of BTOF-matches recorded for each vertex. However, as noted in step (3), I think these tracks that were BTOF-matched in PPV but not in Sti are still generally recorded as primary.
5. StBTofMatchMaker runs, and assigns tracks to hits in the BTOF collection [1]. This is yet another instance of BTOF-matching code (importantly though, this is the TOF-group supported instance!), and it is far from a duplicate code, so it would require more effort for me to understand its matching scheme (the TOF group likely already understands this code much better). We should not assume that it yields identical results to either the Sti or PPV BTOF-matching codes.
6. StMuDstMaker runs, looping over BTOF hits to see if they have an associated track. If so, the associated StMuTrack will have the index of that BTOF hit [1]. In other words, the MuDst tracks have BTOF-matching based on StBTofMatchMaker, and this is what is used when PPV is used to re-do vertex-finding from the MuDst [2].

---

Summarizing some key points:

1. As implemented, coarse BTOF-matching is indeed required for all tracks used in PPV vertex-finding when the UseBTOFMatchOnly option is enabled.
2. Vertices in the MuDst properly store the number of tracks used in vertex-finding, but the number of BTOF-matched daughters is calculated from both a different set of requirements on the tracks, and a stricter definition of BTOF-matching.
3. Tracks in the MuDst use yet a different code for their definition of BTOF-matching (which is the TOF-group supported version, and perhaps can be therefore labeled as the "official" definition).

I advocate modifying the reconstruction chain to split Sti so that there is an official split between global track-finding, and primary-track-finding. Between those would be two chain components: any track-to-fast-detector matchers (e.g. StBTofMatchMaker), then the vertex-finder. This will require notable re-arrangements of code, particularly within StiMaker.

---