PHP 8.6 llega el 19 de noviembre de 2026, y ya sé con qué feature abrirá cada charla de conferencia: la aplicación parcial de funciones. Escribes str_replace(' ', '-', ?) y obtienes un callable con el último argumento abierto, listo para encajar en el operador pipe. Es genuinamente precioso, y después de años de closures envoltorio fn($x) => ensuciando nuestros pipelines de colecciones, lo acepto encantado. Pero mi tesis real es esta: PFA son los fuegos artificiales, no la obra en construcción. Las partes de 8.6 que más importarán dentro de tres años son las que hoy parecen aburridas: las palabras reservadas, las deprecaciones y una API de polling que deliberadamente llega sin la pieza que todo el mundo quiere.

Empecemos por los identificadores de los que PHP ahora te advierte: let, is, namespace como ciertos nombres, readonly como nombre de función y el guion bajo solitario _. Un lenguaje no acordona palabras como let e is por diversión. Eso es el equipo de core reservando plazas de aparcamiento para sintaxis futura — el pattern matching es la apuesta obvia para is — y haciéndolo una versión mayor entera por adelantado, para que el eventual RFC no rompa medio Packagist. Si alguna vez has visto a un lenguaje intentar meter una palabra clave con calzador a posteriori, sabes cuánto dolor evita este movimiento silencioso.

La nueva API de polling cuenta la misma historia. Le da a los internals de PHP — PHP-FPM, el manejo de señales, ZTS — una abstracción decente sobre epoll y WSAPoll, y está expuesta a userland para que ReactPHP y Amp puedan jubilar sus malabarismos con stream_select(). Y aquí lo crucial: no trae async/await y no trae un event loop. He visto a gente leer eso como timidez. Yo lo leo como secuenciación: no viertes el hormigón y cuelgas el pladur la misma tarde. Si PHP llega a tener async de primera clase, se apoyará exactamente en este tipo de fontanería sin glamur, y mientras tanto las aplicaciones de alta concurrencia ganan escalabilidad.

La lista de deprecaciones se lee igual en cuanto entrecierras los ojos. Hacer return desde un finally — ese pequeño disparo al pie donde un return [] en el bloque finally se traga silenciosamente el return $value del try — por fin está en la lista negra. Los constructores y destructores que devuelven valores, que nunca significaron nada, ahora también están oficialmente deprecados. Reflection se está apretando: asignar propiedades en objetos no relacionados y llamar a métodos estáticos a través de instancias están ambos marcados para eliminación. Cada una de estas cosas cierra una puerta que alguna feature futura tendría que esquivar de puntillas. Y sí, is_double(), is_integer(), is_long() y doubleval() salen por la puerta en favor de is_float(), is_int() y floatval(); si eso rompe tu código, a tu código ya le tocaba una pasada de rector de todas formas.

Déjame conceder el contraargumento más fuerte, porque es bueno: para quien programa a diario, lo inmediatamente útil es lo que paga las facturas, y 8.6 trae de sobra. clamp($value, 0, 100) sustituye al conjuro max(0, min(100, $value)) que todos hemos tecleado mal alguna vez, y funciona con strings, DateTime, cualquier cosa comparable. Las propiedades readonly ya pueden llevar valores por defecto. Reflection gana isReadable() e isWriteable(), que los autores de frameworks que lidian con property hooks y setters privados usarán desde el primer día. ReflectionParameter::getDocComment() pone las anotaciones justo al lado del parámetro que describen. Los enums ganan __debugInfo(), así que la salida de var_dump() deja de ser arqueología. Si tu definición de una buena release es «cosas que uso este sprint», 8.6 supera el listón sin nada de mi romanticismo arquitectónico.

Pero sigo aterrizando donde aterrizo, y los valores por defecto de sesión son la razón. session.use_strict_mode = 1, session.cookie_httponly = 1, session.cookie_samesite = Lax — de serie. Nadie va a bloguear con entusiasmo sobre defaults de ini, y sin embargo este único cambio matará en silencio toda una clase de bugs de session fixation y robo de cookies en miles de aplicaciones cuyos mantenedores jamás leyeron el changelog. Ese es el patrón que estoy señalando: las decisiones sin sex appeal se acumulan con interés compuesto. El enum SortDirection es otra pista — lanzado antes de que las funciones de ordenación del core siquiera lo acepten, puramente para que el ecosistema pueda estandarizarse ya y el lenguaje se ponga al día después. Eso es un proyecto planificando en décadas, no en ciclos de release.

Consecuencia práctica para tu actualización: no trates 8.6 como un bufé de features en el que picotear cuando te apetezca. Ejecútalo en CI con las deprecaciones tratadas como fallos la misma semana en que salga. Los returns en finally, los helpers de tipos legacy, los trucos de reflection en ese serializador ancestral que vendorizaste en 2019, las llamadas a spl_object_hash(), mysqli::stmt_init() — cada uno que arregles ahora es una migración que no harás bajo presión cuando llegue PHP 9. Y comprueba si algo en tu stack depende de POSTs cross-site que toquen sesiones o de JavaScript leyendo IDs de sesión, porque los nuevos defaults de cookies morderán primero exactamente a esos montajes.

Así que aquí es donde quiero que me lleves la contraria, porque sé que en esta sala hay gente que discrepa. ¿Se juzga mejor una release por lo que te deja escribir hoy o por lo que hace posible en tres años? Dicho de otro modo: ¿qué cambio de 8.6 seguirá importando en 2029 — PFA y el operador pipe, o el día en que PHP reservó la palabra is? Dime que me equivoco en los comentarios; trae código.