Good catch. I wonder whether we could improve inference for promote_typejoin. Maybe the problem is due to the removal of the @_pure_meta annotation in join_types? If so, we could define the function differently (using a loop with @eval rather than passing the function as an argument) so that it can be marked as pure again.

I had tried renaming all existing promote_typejoin methods to _promote_typejoin and replacing the former with

promote_typejoin(@nospecialize(a), @nospecialize(b)) = _promote_typejoin(a, b)

Curiously, for an example where the generator could return either a Bool or a String, that tightened inference of intermediate results in collect from Vector to Union{Vector{Bool},Vector{String},Vector{Any}}, but the end result was then the wider AbstractArray. And I admittedly was to lazy to figure out what was going on...

But more directly to your question: No, I don't think removal of @_pure_meta would have caused this. IIUC, the number of methods to consider for promote_typejoin(::Any, ::Any) is large enough for inference to bail out anyway.

Rebased and reworked this.

One interesting problem to inferring promote_typejoin(a,b) is illustrated by the following:

julia> foo(::Type{T}) where {T} = Union{Missing, T}
foo (generic function with 1 method)

julia> code_warntype(foo, Tuple{Any})
Variables:

Body:
  begin
      Core.SSAValue(0) = (Core.apply_type)(Main.Union, Main.Missing, $(Expr(:static_parameter, 1)))::Any
      return Core.SSAValue(0)
  end::Any

I think it should be safe to always infer Union{...} as Type, but that doesn't happen. So I've introduced a wrapper function with a type-assert.

That does sound reasonably safe. It looks like currently apply_type_tfunc just instead returns Any when it gives up.

I guess this means "Approved"?