What does C++11 consider to be a "thread"?

Only components from the thread support library count because of these quotes, or main which the standard states runs in its own thread of execution.

1 The following subclauses describe components to create and manage threads (1.10), perform mutual exclusion, and communicate conditions and values between threads, as summarized in Table 148.

The link to 1.10 implies that the threads being spoken about are these.

1 A thread of execution (also known as a thread) is a single flow of control within a program, including the initial ...

Therefore it seems to me threads only refer to the stdlib threads (meaning std::thread and anything the thread support library does internally). Of course thread_local in many cases could end up working with the native threads (especially when you consider on a specific system you don't usually have more than one choice for implementing threads) but as far as I can tell the standard makes no guarantee.

C++11 §1.10/1 defines the terms:

A thread of execution (also known as a thread) is a single flow of control within a program, including the initial invocation of a specific top-level function, and recursively including every function invocation subsequently executed by the thread. [ Note: When one thread creates another, the initial call to the top-level function of the new thread is executed by the new thread, not by the creating thread. — end note ]

The italicized terms indicate that this is definitive. You could argue that this definition is mathematically deficient, because each function invocation defines a new thread, but that's just obviously wrong. They mean maximal single flow of control, otherwise the non-normative note would cancel the effect of the normative "recursively including" text.

From the standpoint of the core language, it is merely incidental that std::thread causes such a thing to exist.

What if I use a library that provides user-space threads - does each of those get its own copies of thread_local objects (I don't really see how that could be implemented)?

There is no way to write such a library without kernel calls. In all likelihood all threads in your process are already represented a high-level abstraction such as pthreads, just to satisfy the kernel. The C++ standard library is likely written against the native threading library to "just work" without additional glue.

For example, thread_local objects are initialized at first access rather than when each new thread starts, so the compiler just has to insert a query based on pthread_self to access and perhaps initialize. Initialization would register a destructor with the pthread_cleanup facility.

What is implementation-defined here is whether the pre-existing native library is compatible with C++. Supposing they provide that, and it's something customers would tend to want, all other threading libraries built atop it will be automatically compatible barring some other conflict.

The standard does not describe how threads produced by other libraries and system calls behave. They are, as far as the standard is concerned, undefined in their behavior. There is no other way, within C++ proper, to create multiple threads: such libraries or system calls do things that are not standardized by the C++ standard.

Now, each such library and system call will behave in ways defined by its own specs. Quite often, the C++ std::thread will even be built on top of such libraries or system calls. How exactly the interaction works is not specified.