We don't want to say the implementations should inline all functions marked inline, because that's too strong. It's a hint that the function should be considered for inlining but what does "considered" mean in terms of the standard? How do we phrase it to account for differing inlining heuristics at different optimization levels?

But what is the actual recommendation here? I don't think this fits the form of Recommended practice.

We don't want to say the implementations should inline all functions marked inline, because that's too strong. It's a hint that the function should be considered for inlining but what does "considered" mean in terms of the standard? How do we phrase it to account for differing inlining heuristics at different optimization levels?

Do you mean that this paragraph here can't be Recommended practice in general here, or do you mean that it needs to be softened up even more?

I think the overall form is definitely recommended practice. However, it would be worth stating something like:

This user should be able to indicate to the implementation that this substitution should be omitted for the purpose of debugging.

This would be satisfied by having a flag that disables inlining in general, or optimization level flags. It might be beyond the scope of the standard to recommend "optimization levels" to exist, or that different inlining heuristics should be used at those levels.

The \keyword{inline} specifier indicates to
the implementation that inline substitution of the function body at the
point of call is to be preferred to the usual function call mechanism.

What is the recommendation here? An implementation should ... what?

Maybe it could be phrased as "An implementation should treat the inline specifier as a hint to prefer inline substitution of the function body at the point of call instead of the usual function call mechanism."

But do we want to phrase that in terms of the inline specifier, rather than in terms of inline functions? Does that mean an implicitly inline function (one declared in the class definition, or using constexpr) should not be inlined, because it doesn't use the specifier?

I don't think we should bother changing this text unless the new version is clearly better, rather than just bad in different ways.

I guess it might be better to remove normative texts about inline substitution or turn them into notes, because inline substitution shouldn't be observable in standard semantics, although it may affect results from implementation-defined or unspecified properties.

Yeah. Implementations should treat the inline specifier (or implicit inline-ness) as a hint that can be completely ignored at any given call site if e.g. optimization is disabled, or the compiler's unspecified heuristics decide inlining would not be beneficial.

And implementations might inline functions that aren't inline functions anyway, so the hint isn't even required in some cases.