Moi j'aurais vu un truc un peu comme ce que propose Godzil, mais un peu plus flexible peut-être: en gros une table TOPIC_VIRTUEL(id_virtuel, id_categorie, id_reel) qui pointe sur une table TOPIC_REEL(...) comme celle actuelle mais sans la référence catégorie, et les topics vus par les utilisateurs sont les virtuels, seuls les modérateurs ont accès aux id réels pour créer les alias. En fait c'est un peu le principe des liens (physiques, pas symboliques) sous linux si je ne dis pas de bêtises (?)
Après on peut compacter cette idée (même si je trouve ça un peu crade ) pour ne garder qu'une table de topics (avec un champ "forward" par défaut à null, et qui pointerait sur l'id de topic réelle pour un alias), mais j'ai l'impression que c'est déjà un peu à ça que tu penses ?

Après pour mes sujets, je ne vois pas trop de problèmes, stocker l'ID du topic réel comme avant (enfin je fais des suppositions sur les données je ne connais pas la structure exacte), quelle que soit la solution retenue, et stocker l'alias principal qui a été choisi par l'utlisateur (en gros on ne peut s'abonner qu'une seule fois à un vrai topic, mais on peut "choisir" l'alias, donc la catégorie que l'on veut, c'est pas une bonne idée ? )
Pour les !call, je pense que ça importe peu à la personne concernée de se faire apeller dans une catégorie où une autre, vu qu'il y a autant de chances pour que la catégorie originale ne lui plaise pas, que pour que ça soit la secondaire...
(Pour tout ce qui est comptage de posts, affichage du nom par contre je ne sais pas comment c'est géré avec le système actuel, mais moi je gèrerais ça à coup de forward "si le topic est un alias, fais une seconde recherche dans la table avec l'id de référence", soit en une seule requete, soit en deux, je ne sais pas ce qui est mieux, mais à priori deux requetes serait pas mal vu qu'on ne risque pas de croiser des alias tous les 4 matins => ralentissement occasionnel donc minimum ?)