La votación sobre el RFC Deprecations for PHP 8.6 ha pasado, pero la discusión en la lista internals muestra que la propuesta deja preguntas abiertas en torno al manejo de CSV en SPL.

Robert Humphries plantea dos objeciones. Primero, el RFC no indica a qué debería migrar el código existente. El código construido alrededor de SplFileObject::fputcsv() no puede simplemente pasar a la función procedural fputcsv(), porque esta espera un recurso de stream y no es un reemplazo directo.

Segundo, el flag SplFileObject::READ_CSV no forma parte de la deprecación. setCsvControl() es la única vía para configurar el delimitador, el enclosure y el carácter de escape para READ_CSV, ya que el constructor no los acepta. Si setCsvControl() desaparece en PHP 9 mientras READ_CSV permanece, el flag queda fijado a sus valores por defecto y los archivos separados por tabulaciones ya no podrán leerse por esa vía. El valor por defecto de $escape está además ya deprecado y cambiará.

Humphries concluye que o bien READ_CSV debería deprecarse junto con los cuatro métodos, o bien setCsvControl() debería conservarse hasta que exista una API de reemplazo. Una nota posterior señala que, con la votación aprobada, deprecar READ_CSV parece necesario. De lo contrario, el código que use READ_CSV se comportaría de forma distinta según la versión de PHP tras el cambio del valor por defecto de $escape, sin forma de hacerlo consistente manualmente.