Steps to reproduce:
- Download and open the linked project
- Run the menu item NightProbes > B3 ForceBinary Bisect
- Open the resulting .asset files (staged copies are written to %TEMP%\b3-evidence) and compare the byte[]-containing assets against the ones without a byte[] field
Actual results:
Every ScriptableObject that contains a byte[] field is silently reduced to a header-only stub after the round trip: m_Script becomes {fileID: 0}, only m_Name and defaults remain, and all serialized data (the byte[], ints, strings, AnimationCurve, Gradient, [SerializeReference] graphs - everything) is gone. LoadAssetAtPath returns null; the asset is unrecoverable without version control. During the conversion the Console logs "Unable to parse file <asset>: [Parser Failure at line N: Found invalid Unicode character escape code]". ScriptableObjects WITHOUT a byte[] field survive the identical round trip intact.
Field bisect (7 variants, deterministic; re-verified on the trimmed repro project 2026-09-07):
full (byte[]) 10335 B -> 377 B WIPED
nosref (byte[]) 6430 B -> 379 B WIPED
srefblob (byte[]) 5742 B -> 381 B WIPED
sref (no byte[]) 5225 B -> 5304 B intact
unicode (no byte[]) 1397 B -> 1476 B intact
srefuni (no byte[]) 5304 B -> 5383 B intact
srefflts (no byte[]) 9740 B -> 9764 B intact
=> the byte[] field is the exact and only trigger.
Expected results: An Asset Serialization Mode conversion is lossless - that is its documented purpose - so the byte[] and all other serialized data survive the round trip; or, at minimum, the conversion fails loudly and leaves the original asset untouched instead of silently erasing it.
Reproducible with versions: 6000.0.0f1, 6000.0.83f1, 6000.3.24f1, 6000.5.11f1, 6000.6.1f1, 6000.7.0a6
Tested on (OS): Windows 11