Je pense que tout processus impliquant « peut être public, peut être privé » comportera un risque d’erreur humaine chaque fois que quelqu’un crée un sujet. Qu’il s’agisse de choisir la bonne catégorie, de se souvenir de cliquer sur « murmure » ou d’ajouter une balise qui effectue ensuite une magie CSS pour la masquer, etc. Il y a un point où vous devez faire ce choix et une opportunité correspondante de le gâcher. 
Je pense qu’une sous-catégorie est la bonne approche pour avoir confiance dans les protections de visibilité. Si vous ne souhaitez pas activer les sous-sous-catégories pour cela (ou ajuster votre structure de catégorie de niveau supérieur avec une alternative comme Category Groups), vous pouvez avoir une sous-catégorie supplémentaire dans Support pour #internal-bug-reports, puis utiliser le filtre de sujet pour créer une liste de sujets personnalisée incluant les sujets des deux catégories, que vous pouvez ensuite ajouter à la barre latérale pour que vos développeurs l’utilisent.
Juste pour le plaisir, j’ai testé si je pouvais changer le post_type d’un OP via l’API. Et bien que cela ait fonctionné, il est toujours apparu dans la liste des sujets pour un utilisateur de test non-murmure et a ensuite généré une erreur lorsqu’il a cliqué dessus. 
Il semble donc qu’un travail de développement supplémentaire serait nécessaire pour lisser cela (et il peut également y avoir d’autres conflits pour le comportement inattendu lorsque vous commencez à explorer).