No, indeed—that’s definitely an achilles heel of my suggestion. 
Well, another thought: Do you really need the client type in the JD hierarchy? It seems to be the kind of cross-referencing thing for tags are quite apt and/or which might me done in the JD index.
Then you’d have one less “dimension” to model in the JD hierarchy and it could eg. look like this:
100–119 Client 1
101 Project 1
10–19 Legal Matter 1
11 Lots of …
101.11.01 … breathing room …
101.11.02 … down here, too
120–129 Client 2
Of course I have no idea, if 10 legal matters per project would suffice, though, or 20 Projects—you can scale the “stepping“ to your needs, I guess. 
And the hypothetical Index could look something like this:
(Sadly, Numbers does not offer a multi-select field type.)
But if you do need the client-type your current “AC.PRO.ID” approach without a doubt seems to be the better idea.
I my own experience depending on how you categorize and slice things, standard PRO.AC.ID might not be the solution in every case as it might not give you the room you need where you need it—see my own first shot at JD.
(Personally I would try to avoid four numbers, though—I find PRO.AC.ID “unwieldy” enough. But that’s just me. )