mjhjmtu

In new versions of xparse the manual states the following: (in 2. Backwards Compatibility)

One role of xparse is to describe existing LaTeX interfaces, including some that are rather unusual in LaTeX (as opposed to formats such as plain TeX) such as delimited arguments. As such, the package defines some argument specifiers that should largely be avoided nowadays as using them in packages leads to inconsistent user interfaces. The simplest syntax is often best, with argument specifications such as mmmm or ommmm (...)

What kind of problems like that 'inconsistent user interfaces' might exhibit using for example g-parameter or G-parameter?

I'm the author of a class that rely on macros based on these parameters and would be good knowing if authors of LaTeX3'xparse will drop the support of these parameters or what issues on which circumstances might exhibit...

Edit: As not everyone is familiar with the different parameter types the xparse package provides, here's the description for g and G from the documentation:

g: An optional argument given inside a pair of TeX group tokens (in standard LaTeX, ...), which returns -NoValue- if not present.
G: As for g but returns <default> if no value is given: G<default>.

The xparse package is primarily meant to allow definition of 'LaTeX2e-like' commands, though it also can standardise the description of a wider range of interfaces. The LaTeX2e kernel is very consistent in using ... for mandatory arguments and [...] for optional ones ((...) is used for picture-mode arguments). As such, the g-type argument is an outlier: it's not really standard LaTeX2e usage at all. We include it as it does come up in e.g. beamer,

beginframetitlesub-title

Probably, written today one would normally use keyval systems for such cases

beginframe[title = ..., subtitle = ...]

In general, I would avoid using g-type arguments for new commands.