This assertion is too weak and appears to hide a correctness bug in segmented FMIndex search. FMIndex training currently does not request _rowid or _rowaddr, so collect_texts falls back to a local counter starting at 0 for each segment, and search returns those ids as row addresses. With this fixture, "quick" should match 5 rows, but segmented search can collapse local ids across segments and still satisfy >= 3.

Can we fix FMIndex to store global row addresses / stable row ids and make this test assert the exact expected rows or count?

Good catch! I fixed this by:

1. Updating FMIndexPlugin to request global row addresses (.with_row_addr()) during training.
2. Updating collect_texts to parse the global _rowaddr (falling back to _rowid if needed), rather than falling back to local counter starting at 0.
3. Adding a new search_row_addrs method on FMIndex to return the full 64-bit row address during logical searches, avoiding any 32-bit offset truncation.
4. Tightening the test assertion to assert exactly 5 matching rows.

This commit path does not preserve the normal replace=true behavior. The standard execute path removes all existing same-name indices when replace is set, but commit_existing_index_segments only removes overlapping same-type segments. Replacing an existing same-name BTree/bitmap/etc. index with segmented FMIndex can leave mixed metadata under one index name, and empty/untrained FMIndex coverage can leave old same-type segments too.

Can this path either build the transaction with the same removed_indices as the normal path, or extend the segment commit API with explicit replace semantics?

Fixed. I replaced the commit_existing_index_segments calls with explicit TransactionBuilder + apply_commit, collecting all same-name indices into removed_indices when replace=true. This matches the standard execute path behavior and ensures replacing a BTree/bitmap index with a segmented FMIndex properly cleans up all old metadata.

This bypasses the standard execute_uncommitted validation that requires exactly one column. For num_segments > 1, an empty column list will panic here, and a multi-column request silently indexes only the first column instead of returning the existing error.

Can we run the same self.columns.len() != 1 validation before entering the segmented FMIndex path?

Added. execute_multi_segment_fmindex now runs the same self.columns.len() != 1 check at entry, matching execute_uncommitted validation.

This merge path should mirror the btree merge behavior and intersect stored segment coverage with the dataset's current live fragments. As written, it unions historical fragment ids and passes them to build_scalar_index; after compaction retires one of those fragments, the rebuild can fail with No fragment with id ....

Can we use effective live coverage here, and add a compaction/retired-fragment merge test similar to the btree coverage?

Fixed. merge_segments now intersects the unioned fragment bitmap with dataset.fragment_bitmap to drop retired/compacted fragments before rebuilding, mirroring the btree merge behavior. When the intersection is empty (all fragments retired), it produces an empty index instead of crashing. Added test_fmindex_merge_after_compaction_drops_retired_fragments to cover this scenario.

[P1] This new hard requirement for _rowaddr also needs to be reflected in FMIndex update/optimize paths. FMIndexScalarIndex::update_criteria() still returns TrainingCriteria::new(TrainingOrdering::None), so optimize_indices() / append maintenance can build a training stream with only the value column and fail here. Also, FMIndexScalarIndex::update() currently writes a fresh index from new_data only and ignores the existing index plus old_data_filter; if we only add .with_row_addr(), the generic single-segment scalar update path can replace the old FMIndex with one containing only appended rows. Can we either make FMIndex update merge existing rows correctly, or force FMIndex maintenance to rebuild from the full target fragment bitmap instead of taking the single-segment update() shortcut?

Good catch. Fixed both issues:

1. update_criteria() now returns requires_old_data with .with_row_addr(), so the training stream includes all existing + new rows with global row addresses.
2. update() now applies the old_data_filter to exclude deleted/compacted rows before rebuilding the BWT, so the single-segment update path produces a complete index covering both old and new data instead of silently dropping existing rows.

[P1] This filter drops the appended rows in the optimize/append path. Because update_criteria() now uses requires_old_data, load_unindexed_training_data() passes fragments=None and scans all current rows, not just old rows. But the old_data_filter here only describes the selected old segment coverage, so retaining only to_keep / valid removes the unindexed appended fragments from texts before rebuilding. I think FMIndex either needs to rebuild from the intended union fragment set without this old-only filter, or the update path needs a filter that keeps both selected old rows and new/unindexed rows while excluding deleted/retired old rows.

Good catch. The filter now excludes to_remove fragments instead of keeping only to_keep, so both old valid rows and new unindexed/appended rows are retained in the rebuilt index.