@ Mike Byrd... thank you for the great article. I obviously missed it when it first came out and I'm glad they republish such things to give such articles the attention they deserve.
As a bit of a sidebar, these types of indexes create a bit of "excitement" for folks that are into doing Index Maintenance based on Logical Fragmentation.
Since the "F" and "M" in this index almost never changes and the index is based on Gender (which form "silos" or "partitions" within the index") and, within the silos, the rows are inserted into the NCI in an ever increasing fashion because the second column is DateAdd, which is "ever-increasing" and the CustomerID key inherently included from the CI, is also "ever increasing". That means that each "silo" (and I call them that to avoid confusion with "Partitioned Indexes") forms a "perfect index" that will never fragment and will always have a page density near 100 because only "good" page splits (page splits that are append only and don't actually split a page and move half the data from one to another) occur.
The "excitement" comes from the fact (especially if you had more than just two silos in different "low cardinality" indexes), sys.dm_db_index_physical_stats() will very quickly report them as having very high logical fragmentation because of the mid-index inserts at the end of each silo.
The truth is, they never need to be defragmented because they're always referenced by "silo" and each silo is permanently NOT fragmented. My recommendation is that, once you identify them, rebuild them just once (hopefully when you first build them) with a FillFactor of 98 (the "8" looks like the infinity symbol but stood up on end), and then exclude them from your index maintenance.
To make my life easier, I actually do use the FillFactor to mark the "type" of index as follows...
100 - Static. These are typically "Reference" tables that almost never change unless a category or status or etc is added or a "description" is updated.
99 - Ever increasing/append only where rows are added only at the end of the index and no "ExpAnsive" updates occur. It can take years before the "interleaving" of extents with other indexes causes enough fragmentation to get to 5% fragmentation. Interestingly, such "interleaving" is actually deadly to performance and you should watch the number of "segments" such indexes have. It used to be known as "Extent Fragmentation" and is reported in DBCC ShowContig under a similar name and is reported as "fragment_count" in sys.dm_db_index_physical_stats().
98 - Sequential Silos, which I just explained above.
There are other FillFactor values that I define for other causes but I won't bore anyone with the rest. I just wanted to show the relationship of the "Sequential Silos" with other indexes that don't actually need to be defragmented on any kind of regular basis.