Group members under the same Access Specifier

Context
This piece of C++ code:

class Test {
    int a;
public:
    float b;
};

parses to this syntax tree:

(translation_unit [0, 0] - [5, 0]
  (class_specifier [0, 0] - [4, 1]
    name: (type_identifier [0, 6] - [0, 10])
    body: (field_declaration_list [0, 11] - [4, 1]
      (field_declaration [1, 1] - [1, 7]
        type: (primitive_type [1, 1] - [1, 4])
        declarator: (field_identifier [1, 5] - [1, 6]))
      (access_specifier [2, 0] - [2, 7])
      (field_declaration [3, 4] - [3, 12]
        type: (primitive_type [3, 4] - [3, 9])
        declarator: (field_identifier [3, 10] - [3, 11])))))

I'm wondering about how hard it is to group members by access specifier; which would produce something like this:

(translation_unit [0, 0] - [5, 0]
  (class_specifier [0, 0] - [4, 1]
    name: (type_identifier [0, 6] - [0, 10])
    body: (field_declaration_list [0, 11] - [4, 1]
      (field_declaration [1, 1] - [1, 7]
        type: (primitive_type [1, 1] - [1, 4])
        declarator: (field_identifier [1, 5] - [1, 6]))
      (access_specifier [2, 0] - [3, 11]
      (field_declaration [3, 4] - [3, 12]
        type: (primitive_type [3, 4] - [3, 9])
        declarator: (field_identifier [3, 10] - [3, 11]))))))

Note that the second field_declaration is inside the access_specifier thing.

I see two aspects for this:

1. Backward compatibility; where we still need the "implicitly-defined-access-specifier" members.
2. I assume this is not hard to implement (boils down to modifying the access_modifier grammar rule only)

Benefits
I'm trying to write a tool to generate customizable class/object diagrams from C++ headers; using tree-sitter-graph. And having
the access information of members bundled into the syntax tree will enormously simplify things.

Start with the access_modifier grammar rule in the tree-sitter-cpp grammar and inspect how the shown C++ class currently produces its syntax tree. Check the backward-compatibility requirement for implicitly defined access members. Done means members are grouped under the relevant access specifier while existing implicit-access behavior remains available; compare the resulting tree with the examples in the issue.