Proposal
This proposal is to make rolling dice more general, so that it can cover a much wider range of systems and their rolling methods. An example design (though there are others) would be to allow assignment of die results to action/messagelocal variables and add a couple other functions that can examine the results. This would allow reuse of values AND more generic analysis of what happened when generating them.
Example 1:
!=(
hit := 3d6; bodyr := 2d6+1d3; stunm := max(1, 1d61);
is_crit := hit <= 4;
body := (is_crit ? 2 : 1) * bodyr;
stun := body * stunm
) Your sword hit DCV {11 + ocv  hit}{is_crit ? " with a CRITICAL!" : ""},
doing {body} BODY and {stun} STUN.
Example 2:
!=(
hit := 3d6; stun_dice := repeat(1d6, 3);
is_crit := hit <= 4;
stunr := sum(stun_dice);
bodyr := count_gt(stun_dice, 1) + count_eq(stun_dice, 6);
stun := (is_crit ? 2 : 1) * stunr;
body := (is_crit ? 2 : 1) * bodyr
) Your fists hit DCV {11 + ocv  hit}{is_crit ? "with a CRITICAL!" : ""},
doing {body} BODY and {stun} STUN.
Where the new functions shown could be implemented as follows:

repeat(<expr>, n)
 Evaluates the first parameter (an expression)n
times (can be variable), creating an aggregate result type which can be used for more complicated analysis than just numeric arithmetic. 
sum(list)
 Sums the total of an aggregate result as returned byrepeat()
. This could also be the default way of converting to a simple numeric result if an aggregate type is used in numeric arithmetic. 
count_gt(list)
,count_eq(list)
, etc.  Aggregation functions (e.g. like SQLsCOUNT(*)
) which apply some operation to each element in an aggregate result as returned byrepeat()
and produce a useful result. For example, counting the number of entries that meet certain criteria (>
and==
in this case).
Justification
After all the work on flags and such, it must be a bummer to hear that there are still a plethora of rolling methods that it is woefully insufficient for. I’m going to mention two counting methods in a single system, but I’m sure you can see how the problem exists in many other systems, and others may chime in with more examples. A more generic system could actually fulfill all of the features of the dice flags and more…
Let’s say I want to play a game in the Hero System. This system uses only d6s, but there are two common ways of counting effect/damage rolls which are not covered at all by the roll syntax.

Roll BODY and apply a STUN multiplier: This rolls nd6 (plus an optional 1d3 or fixed bonus) for the BODY damage done, and then rolls another die for a “STUN multiplier” that multiplies the first roll to get the STUN damage done. Currently, a roll can’t both be reported and used to produce another custom result. Example 1 above shows how the proposal could resolve the issue mechanically (with a houserules “critical” added in for good measure).

Roll STUN, counting BODY specially on dice: This rolls nd6 (plus an optional 1d3) for the STUN damage, but counts the pips on each die rolled a second time specially to count BODY (roll of 1 is 0 BODY; rolls of 25 is 1 BODY; roll of 6 is 2 BODY). Currently, a die in a roll can only be counted a second time for very specialpurpose “success/failure” mechanics. Example 2 above again shows how the proposal could resolve the issue mechanically.
Currently the only solutions are to ask the player to perform their own laborious calculations (“add up the dice total to…” or “subtract failures from successes and add 3”). This defeats the purpose of having an automated system for computation in the first place, and isn’t really much better than “roll 4d6, show the pips, and let the player interpret the results” for specialpurpose rolling methods that haven’t been covered by the Astral developers. Let the players/GMs/community handle this logic instead!
Alternative
Of course, an even more generic alternative would be to provide some kind of full scripting environment (e.g. Javascript, Lua, WebAssembly…), which could potentially keep local variables, access character stats, access attributes of the map, the game, etc. Hopefully there will be something like this way down the line, but I suggest that a proposal such as above might be easier to implement in a timeframe that’ll make it useful to players a lot closer to NOW, and without having to consider a bunch of security issues and comprehensive API designs and…