Markdown モードで、次のように入力します。
A B
C D
B と C を選択し、A と D を選択せずに、「スポイラーをぼかす」をクリックします。
結果は次のようになります。
A [spoiler]
B
C
[/spoiler] D
そして、結果はスポイラーでぼかされません。
A [spoiler]
BC
[/spoiler] D
次に、リッチテキストモードで再度試してください。次から始めます。
A B
C D
B と C を選択して、スポイラーをぼかします。
段落の区切りが削除され、結果は次のようになります。
A BC D
Markdown モードに戻ると、結果は次のようになります。
A [spoiler]BC[/spoiler] D
この場合、ネタバレはインラインとブロックの両方にはなれないため、どのような結果になると予想されますか？
CSS の事実として、スポイラーはインラインとブロックの両方にはなれないという考えをユーザーに知らせる必要はないと思います。
太字を考えてみましょう。Discourse の bbcode では次のように記述できます。
A [b]B
C[/b] D
または HTML では次のように記述できます。
<!DOCTYPE html>
<html>
<body>
<p>A <strong>B</p>
<p>C</strong> D</p>
</body>
</html>
期待どおりにレンダリングされます。
A B
C D
しかし、DOM の表現は次のようになります。
<p>A <strong>B</strong></p>
<strong> </strong>
<p><strong>C</strong> D</p>
HTML 仕様では、複数ブロックのハイパーリンクについても同様のことが起こるように規定されています。HTML で次のように記述した場合：
<!DOCTYPE html>
<html>
<body>
<p>A <a href="https://example.com.">B</p>
<p>C</a> D</p>
</body>
</html>
HTML 仕様では、_3 つ_のハイパーリンクを持つ DOM 表現になるように規定されています。
<body>
<p>A <a href="https://example.com.">B</a>
</p><a href="https://example.com."> </a>
<p><a href="https://example.com.">C</a> D</p>
</body>
同様の方法で、複数段落のインライン スポイラーをレンダリングすることを想像できます。
<p>A <spoiler>B</spoiler></p>
<p><spoiler>C</spoiler> D</p>
しかし、スポイラーは太字とは異なります。スポイラーは_インタラクティブ_だからです。スポイラーの B 部分をクリックすると、スポイラーの B と C の両方が表示されるはずです。それは「1 つのスポイラー」のように見え、感じるはずです。
これを処理する方法は、DOM 表現でリンクされたスポイラーをサポートすることだと思います。おそらく <spoiler> には name のような属性があり、スポイラーをクリックすると、同じ名前を持つすべてのスポイラーが表示されるようになります。（これは属性、プロパティ、または 3 つのスポイラーをリンクするための他のシステムで行うべきですか？わかりません、好きなようにしてください。）
たとえば、次のような Markdown があるとします。
A B
C
D E
[spoiler]F[/spoiler]
そして、B、C、D を選択してぼかします。
すると、Markdown は次のようになります。
A [spoiler]B
C
D[/spoiler] E
[spoiler]F[/spoiler]
生成される DOM は次のようになります。
<p>A <inline-spoiler name="x">B</inline-spoiler></p>
<block-spoiler name="x"><p>C</p></block-spoiler>
<p><inline-spoiler name="x">D</inline-spoiler> E</p>
<block-spoiler name="y"><p>F</p></block-spoiler>
JS では、3 つのスポイラーのいずれか 1 つをクリックすると、同じ「name」属性を持つすべてのスポイラーが一緒に表示されます。
したがって、エンドユーザーの観点からは、インラインとブロックのスポイラーを自由に組み合わせることができるように 感じられる でしょう。
この件は、現在サポートされていない機能の検討であるため、Bug から Feature に移動しました。
@dfabulich サポートしたいユースケースを共有していただけますか？それによって、ソリューションに最もよくアプローチする方法を理解するのに役立ちます。この形式のインライン + ブロックスポイラーをサポートすることが、コミュニティでどのように役立つか、またはそれらが発生したときに教えていただけますか？
「機能」として分類するのは間違った判断だと思います。
「このバグは修正が難しすぎるため、他の作業よりも優先順位を付けるのは理にかなっていません」と言うことは想像できます。
しかし、現在の動作を正しいと擁護する人は誰もいないと思います。
ご質問については、「ユースケース」をバグ修正に与えることは実際には不可能です。機能にはユースケースがありますが（スポイラーのぼかし：ユーザーはネタバレをぼかして、驚きを損なうことなくメディアについて議論できるようにしたい）、バグは機能の内部に存在します。バグを修正することが、機能がユースケースを満たす方法です。
この問題を「バグ」として扱い、提案したソリューションの実装が高価になる可能性があることを認めると、ご質問の「ユースケース」に答えるためにできる最も近いことは、別の質問に答えることです。
「このバグが重要なのはなぜですか？ 現在の動作が間違っていることを認めると、インラインテキストを複数の段落にまたがってぼかすことができないことを誰が気にしますか？ 本当にそれを行う必要がありますか？」
そしてそれに対して、私は次のように言うでしょう。現在のエクスペリエンスは混乱を招くだけで、Discourseに対するユーザーの信頼を損ないます。テキストを選択して「スポイラーのぼかし」をクリックしても、選択したテキストがぼやけない場合、関係者全員にとって恥ずかしいことです。
正直なところ、ユーザーが2つの段落の一部をスポイラー化しようとしたときにエラーメッセージを表示し、問題の性質についてユーザーに教育することは、現在の動作よりもわずかな改善になります。エラーメッセージには、「Discourseでは、1つの段落の一部をスポイラー化するか、1つ以上の段落全体をスポイラー化できますが、2つ以上の段落の一部を含むスポイラーを作成することはできません。」と表示される可能性があります。
しかし、太字のテキストや斜体のテキストでそのようなエラーを表示する必要があるとしたらどうでしょうか？
そして、それがスポイラーが私にとって重要である理由につながります。私が運営しているフォーラム（および私が参加している他のDiscourseフォーラム）はゲーマーフォーラムであり、メディアについて話すこと、特にパズルの解決策をネタバレせずに話すことは非常に重要です。
「スポイラーのぼかしは太字のテキストほど重要ではありません。太字のバグは複数の太字セクションを作成することで修正しますが、スポイラーのぼかしについては、より大きな問題があります。スポイラーのバグを修正しないでおきましょう。スポイラーはあまり気にしません。ユーザーは回避策を見つけるでしょう。」と言う人がいることは理解できます。
しかし、私や私のフォーラム、そして私が住んでいるフォーラムにとっては、スポイラーのぼかしは太字のテキストよりもわずかに重要です。だからこそ、私はこれらのスポイラーのぼかしバグに取り組んできたのです！
「ユースケース」とは何ですか？ ユースケースは次のとおりです。驚きを損なうことなくメディアについて話すためにスポイラーを使用します。したがって、ぼかしスポイラー機能は、そのニーズを満たすために機能し、正しく機能する必要があります。
私としては、バグと機能の両方があると考えています。意味論については意見が分かれるかもしれませんが、ネタバレがあなたやあなたのコミュニティにとってどれほど重要であるかを考慮し、次に何が起こるかを理解していただくために、私たちがどのようにこれを見ているかを説明したいと思います。
バグとは、インラインでブロックをまたいでネタバレを適用しようとすると、段落の区切りが（リッチテキストモードでは）削除され、（Markdownモードでは）追加されることです。
リッチテキスト：
Markdown：
これは快適な体験ではないことに同意します。そのバグを修正することは可能ですが、その場合、以下のいずれかのようになります。
機能リクエストは、インラインで開始して複数のブロックにまたがり、1回のクリックで表示できる単一のネタバレをサポートすることです。これはネタバレの設計された動作ではありません。
ユースケースについて質問したのは、バグの修正と機能の重要性の理解の両方に役立てるためです。通常、ネタバレはインラインまたはブロックとして表示されるため、インライン+ブロックのネタバレが特に役立つ状況があるかどうかを知りたいです。これにより、Discourseの利用方法を理解し、これを解決することがどのように役立つか（そしてここで共有された内容に自身のコミュニティのニーズを認識する他の人々にも）を理解するのに役立ちます。
2つの選択肢を考慮すると、「単一のスポイラーだが、選択されたコンテンツは独自のブロックに強制される」を選びたいと思います。
これにはユースケースに基づいた理由は特にありません。強制ブロックの動作はまだバグがあると思いますが、
強制ブロックのオプションは、スポイラーの見た目に影響するだけで、「バグが少ない」と感じます。スポイラーの最初と最後に余分な改行が追加されるだけです。
リンクされていない複数のスポイラーは、スポイラーの動作に影響します。読者は、先頭のインラインスポイラー、次にN個のブロック内のスポイラー、そして末尾のインラインスポイラーと、最大3回クリックしてスポイラー全体を表示する必要があります。
強制ブロックのスポイラーの場合、これは化粧的なハードバグとなり、誰も作業しない可能性のある種類のものになります。
このフレームワークは理にかなっています。
修正に取り組みます。ETAはまだありませんが、対応が完了したらここで更新します。