BitMap presently has

get_next_one_offset(idx_t)
get_next_one_offset(idx_t, idx_t)
get_next_one_offset_inline(idx_t, idx_t)
get_next_one_offset_inline_aligned_right(idx_t, idx_t)

get_next_zero_offset(idx_t)
get_next_zero_offset(idx_t, idx_t)
get_next_zero_offset_inline(idx_t, idx_t)
// no inline_aligned_right because no callers

The one-argument get_next_{zero,one}_offset functions are simple inline wrappers for calling the corresponding two-argument function with the bitmap's size() as the second argument.  No issues there.

The two-argument get_next_{zero,one}_offset functions are commented in BitMap.hpp as being not-inline, but are declared inline in BitMap.inline.hpp. And many (most?) callers are performance sensitive.  There are probably no callers that truly need a non-inline call; there are probably some that don't care.

The only direct outside callers of the _inline suffixed are a few functions in ParallelGC.  So all other BitMap searchers are using the unsuffixed variants, even where performance critical.

The API would be made less confusing by dropping the _inline suffixes and removing the pre-existing non-suffixed two-argument variants.