Muhammed Arshid KV propuso deprecar los métodos CSV de SplFileObject — fputcsv(), fgetcsv(), setCsvControl() y getCsvControl() — dentro de la RFC de deprecaciones para PHP 8.6. Su argumento: estas API son complejas y difíciles de mantener, y los argumentos nombrados evidencian inconsistencias de diseño que causan problemas desde hace tiempo. Sugirió reemplazarlas por una extensión dedicada ext/csv con una API CSV más limpia y orientada a streams, enlazando el pull request php-src#22160.

Gina P. Banyard, autora de la RFC agrupada, se mostró dispuesta a incluir una propuesta redactada (preferiblemente en formato DokuWiki, aunque acepta Markdown), pero aclaró que no la escribiría ella misma.

Ignace Nyamagana Butera objetó que deprecar la API actual sin siquiera el inicio de un reemplazo es prematuro. En su opinión, PHP debería ofrecer primero una mejor experiencia CSV; solo cuando la comunidad acuerde una nueva API, esta se use de forma extendida y exista un camino de migración sencillo tendría sentido hablar de deprecación.

Takuya Aramaki respaldó la objeción cerca del cierre de la votación con dos puntos concretos. Primero, la RFC no indica a qué debería migrar el código existente: la función procedural fputcsv() no se ve afectada, pero requiere un recurso de stream, por lo que no es un reemplazo directo para código construido sobre SplFileObject. Segundo, el flag SplFileObject::READ_CSV no forma parte de la propuesta. Dado que setCsvControl() es la única forma de configurar el delimitador, el enclosure y el carácter de escape que usa READ_CSV (el constructor no los acepta), eliminar setCsvControl() en PHP 9 manteniendo READ_CSV dejaría el flag fijado permanentemente en sus valores por defecto — y el valor por defecto de $escape ya está deprecado y previsto para cambiar. Sostiene que READ_CSV debería deprecarse junto con los cuatro métodos, o que setCsvControl() se conserve hasta que exista un reemplazo.