これで納得がいきました。ユーザーが行っているのは、DiscourseではなくWordPressでアカウントを登録しているということです。DiscourseConnectを使用していると、ユーザー視点では少々混乱を招く可能性がありますが、それはおそらく別の問題でしょう。
現在、ユーザーはDiscourseの「ログイン」ボタンをクリックします。WordPressサイトのログインページにリダイレクトされます。そこからサイトの登録ページに移動する必要があります（ここが混乱の原因です）。サイトで登録した後、アカウントを有効化するように求めるメールが_WordPress_から送信されるはずです（これはWordPressサイトの設定によります）。WordPressサイトのデフォルトの登録設定がされている場合、ユーザーは有効化メール内のリンクをクリックし、WordPressアカウントを有効化してサイトにログインする手順を踏みます。
WP Discourseの「ログイン時にDiscourseユーザーを作成または同期する」オプションが有効になっている場合：
WordPressにログインすると、Discourseユーザーが自動的に作成されます。WordPressでこのオプションが有効になっていない場合、Discourseユーザーは、Discourseの「ログイン」ボタンを再度クリックするか、WordPressサイトに追加したDiscourseログインリンクをクリックするまで作成されません。
いずれの場合も、Discourseユーザーが作成されると、Discourseサイトに「承認待ち」のレビューエントリが作成されます：
Discourseサイトのスタッフは、承認待ちのユーザーがいることを通知されます。スタッフがユーザーを承認すると、Discourseから「承認されました」というメールがユーザーに送信されます。
これは、Discourseサイトへのユーザーアクセスを許可するための非常に複雑なアプローチのように思えます。ユーザー視点から見て、これを最も簡単に簡素化する方法は、Discourseの must approve users 設定を無効にすることです。WordPressサイトに、Discourseサイトへのアクセスを許可したくないユーザーがいる場合は、WordPressサイトにコードを追加して、一部のユーザーがDiscourseにログインできないようにする方が良いでしょう：How to prevent some WP users from being able to login to Discourse - #2 by simon
DiscourseConnectが有効になっている場合に must approve users 設定を有効にする良いユースケースはないと思います。ユーザー視点では非常に混乱します。
DiscourseConnectが有効になっている場合に、DiscourseまたはWordPressのいずれにもアカウントを持っていないユーザーがDiscourseの「ログイン」ボタンをクリックするという問題について、良い解決策を見つけたいと思います。おそらくDiscourseは discourse connect signup url 設定を追加するかもしれません。設定されていれば、ユーザーは認証プロバイダーのログインページではなく、認証プロバイダーのサインアップページにリダイレクトされるようになります。今のところ、最善の解決策は、認証プロバイダーのログインページで「登録」リンクをわかりやすくすることです。デフォルトのWordPressログインページでは、それほどわかりやすくありません：
