Since the 2025-06-01 LaTeX kernel update, the new socket build/column/baselineattach lets us attach bottom floats using the baseline of the last text line.
With \AssignSocketPlug{build/column/baselineattach}{on}, \textfloatsep is now added from the baseline and descenders in the last line no longer affect the spacing.
However, \intextsep is still measured from the depth of the last line, not from the baseline. So the vertical space above an h-float changes depending on whether the previous line contains descenders. This produces inconsistent spacing between h-floats and b-floats.
In the example image below, the spacing between a paragraph without descenders and an in-text float is 4.25 mm, while with a descender in the last line it becomes 4.94 mm. In contrast, the spacing to a b-float (which uses \textfloatsep and is affected by the socket baselineattach) matches the first value (within measurement uncertainty), confirming that only \intextsep still behaves differently.
Is it possible to patch the output routine so that \intextsep behaves like \textfloatsep, i.e., is also attached to the baseline?
I attempted to patch the output routine command \@addtocurcol directly by inserting a negative space equal to \theprevdepth, but this failed with compilation errors — presumably because \theprevdepth is not available at that point in the output routine.
Here is a MWE :
\documentclass{article}
\setlength{\textfloatsep}{\intextsep}
\AssignSocketPlug{build/column/baselineattach}{on}
\AssignSocketPlug{build/column/outputbox}{floats-space-footnotes}
\raggedbottom
\begin{document}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit, vestibulum ut, placerat ac, adipiscing vitae, felis. Curabitur dictum gravida mauris. Nam arcu libero, nonummy eget, consectetuer id, vulputate a, magna. Donec vehicula augue eu neque. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Mauris ut leo. Cras viverra metus rhoncus sem. Nulla et lectus vestibulum urna fringilla ultrices. Phasellus eu tellus sit amet tortor gravida placerat. Integer sapien est, iaculis in, pretium quis, viverra ac, nunc. Praesent eget sem vel leo ultrices bibendum. Aenean faucibus.
\begin{figure}[h]
\rule{\textwidth}{2cm}
\end{figure}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit, vestibulum ut, placerat ac, adipiscing vitae, felis. Curabitur dictum gravida mauris. Nam arcu libero, nonummy eget, consectetuer id, vulputate a, magna. Donec vehicula augue eu neque. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Mauris ut leo. Cras viverra metus rhoncus sem. Nulla et lectus vestibulum urna fringilla ultrices. Phasellus eu tellus sit amet tortor gravida placerat. Integer sapien est, iaculis in, pretium quis, viverra ac, nunc. Praesent eget sem vel leo ultrices bibendum. Aenean faucibus. Morbi dolor nulla, malesuada eu, pulvinar at, mollis ac, nulla. Curabitur auctor semper nulla. Donec varius orci eget risus. Duis nibh mi, congue eu, accumsan eleifend, sagittis quis, diam. Ut purus elit, vestibulum ut, placerat ac, adipiscing vitae, felis.
\begin{figure}[h]
\rule{\textwidth}{2cm}
\end{figure}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit, vestibulum ut, placerat ac, adipiscing vitae, felis. Curabitur dictum gravida mauris. Nam arcu libero, nonummy eget, consectetuer id, vulputate a, magna. Donec vehicula augue eu neque.
\begin{figure}[b]
\rule{\textwidth}{2cm}
\end{figure}
\end{document}

\newpageafter?baselineattachsocket therefore corrects a limitation in LaTeX’s handling ofb-floats and delivers the expected result. However, the behaviour ofh-floats is not "corrected", and this is what I would like to address.h-float andb-float consistent and this MWE is here to illustrate that it is currently not the case. The newbaselineattachsocket fixes this forb-floats, buth-floats still use the depth of the last line, which leads to inconsistent spacing when there are descenders. So the issue is not float placement, but typographic spacing.htype floats are typographically problematic anyway, so the other option is just not to use them. note that you should never usehas the sole specifier for a float. latex will change it automatically tohtin any case.