I don't believe you're trying to solve the right problem.
A community of practice and a working group are two fundamentally different types of groups. A community of practice is a group of people centered around learning and improving. A working group is a group of people dedicated to achieving specific goals or outcomes. In my experience, people self-select into a community of practice, while they are nominated (perhaps self-nominated) and selected into a working group based on their ability to help the group move toward the goals. Clearly establishing the purpose of the group is essential.
In an organization with multiple products, perhaps across multiple portfolios, I'd be hesitant about a working group for Scrum Masters that stretches across all of the products and portfolios. If impediments and improvements are being addressed in that way, it almost seems like ways of working are being pushed upwards from the team to higher organizational levels, reducing the ability of the individual teams to self-organize and self-manage around the work and their ways of working.
In some cases, it does make sense for Scrum Masters to work together. For example, if there are multiple teams working on the same product and there is more than one Scrum Master for these teams, then a collaboration session for the Scrum Masters to look for common impediments or improvement suggestions may be useful. However, since the teams are working on a common product, taking lessons from scaling frameworks like LeSS, Nexus, or Scrum@Scale may be beneficial. LeSS and Nexus both use a two-phase retrospective with the team-level Sprint Retrospective first followed by a retrospective for all of the teams collaborating on a product, while Scrum@Scale has a Scaled Retrospective that includes each team's Scrum Masters. The important thing is that the scope of these are limited to the teams that need to collaborate to deliver a single product.
My suggestion would be to look at these common scaling frameworks and how your organization aligns. If you have one Product Owner per Scrum Team, even when there may be multiple teams working on the same product, is that person really a Product Owner? Do you need multiple Scrum Masters for multiple teams working on the same product? From here, I'd look at your overall product and portfolio management and if there is a need to have some level of coordination between separate products within a portfolio of related products.
In my opinion, the better thing to do would be to follow some of Barnaby Golden's advice. Some examples of things that I'd consider valuable would be a book club, organizational-sponsored certification and study groups, outside speakers on Scrum and agility (bonus points for an industry-specific focus), sharing stories from each team about problems and how they were overcome. Instead of trying to make it a working group, make it a community of practice that people want to self-select into. If people want, but are unable, to self-select into the community of practice, figure out why and enable people to join.
