The paper does not change the de jure status quo of this concern; however,
I will note that it probably changes the situation in practice:
_Thread_local is more like C++'s constinit thread_local than plain
thread_local.

I cannot recommend for users of C to adopt using thread_local for mixed
C/C++ uses because thread_local for C++ is more expensive than
_Thread_local is in C.
C++ uses of a thread_local variable from a translation unit that does not
define said variable must, for deferred-initialization implementations
(i.e., all implementations I am aware of), assume that the variable may
have dynamic initialization/finalization.

I should also point out that it is a reality of some existing
implementations that variables defined _Thread_local in C will fail to link
when uses in C++ are declared thread_local (without constinit). It is a
reality with more existing implementations that variables defined
thread_local in C++ with dynamic initialization/finalization could end up
uninitialized/unregistered when accessed via _Thread_local declarations in
C.

This paper exacerbates the confusion between C's _Thread_local and C++'s
thread_local.

-- HT