I can imagine someone would want to read it as an article, but respond to it as threads. That could be handled by a toggle.
I guess I could write a NIP PR for this. 🤔 Don't know if there is one for threads, already. Have to go look.
Discussion
No need for a NIP for this.
It's up to each client to pick how and in what order they show kind1's.
Thread = an npub commenting on his own kind1's, basta.
It's a bit more complicated on a decentralized platform.
1) There needs to be a base K01-note and reply K01-notes, that are all published at once.
2) The reply notes need to stay in a specific order or be numbered (1/5), otherwise it gets confusing because clients reorder notes and there's no clear way to tell which note came first, except maybe timestamp.
3) they need to be identifiable as a cohesive thread, so that a change from thread-view to article-view doesn't accidentally pick up more replies from the same author in the same thread.
This could all just be done with a tag, or some standard keyword in the content that clients could choose to interpret or ignore.
Long-form threads would probably require an index. Be too messy, otherwise.
But, you're right. No need for a NIP for K01 threads, since it could just be ignored and displayed as note-with-self-replies.
Timestamp fixes all of this.
Clients can choose to display all replies from the same author within a certain timeframe as the main thread.
And I would even prioritise later replies from the same author too.
You would have to time the publishing, then. I think the time-stamp is seconds.
1. Time period can be quite long (days or even Infinite). Not sure what Twitter had but you could make threads longer days after the first post.
2. The thread creation tool is everytjing. 
This is one example I made way back. Typefully and Threads (meta app) also nail this.