In BSONElement, accessors have varying degrees of safeness which aren't entirely clear from the naming. We should assess our nomenclature to make their status clear, BF-35346 resulted from one being used in an unsafe manner.

From my initial investigation, we can categorize them into 4-5 levels of safety:

Checks for type correctness and uassert if needed

String()
checkAndGetStringData()
Date()
Number()
Decimal()
Double()
Long()
Int()
Bool()
Array()
OID()
Obj()
Val(Type& v)
toString(...)
jsonString*
exactNumberLong()
embeddedObjectUserCheck()
codeWScopeCode()
codeWScopeCodeLen()
codeWScopeScopeData()
uuid()
md5()
dbrefNS()
dbrefOID()

Unsafe - could have memory faults if type is incorrect

boolean()
date()
_numberDouble()
_numberInt()
_numberDecimal()
_numberLong()
__oid()
valueStringData()
_binDataVector()
timestampTime()
timestampInc()
timestampValue()

Uses MONGO_verify, will check and assert in prod, will invariant in debug

embeddedObject()
codeWScopeObject()
binData(...)
binDataClean(...)
binDataType(...)
regex()
regexFlags()

Memory safe, but may have undefined/inconsistent behavior

numberInt() - behavior undefined for incompatible doubles
numberLong() - behavior undefined for incompatible doubles
safeNumberLong() - may have some different behavior from older versions
numberDouble() - behavior undefined for NaNs or numbers too big/small

Safe

booleanSafe()
safeNumberInt()
safeNumberLongForHash() - preserves edge-case behavior from older versions
all StatusWith functions
numberDecimal()
number()
safeNumberDouble()
valueStringDataSafe()
str()
timestamp()