Bug with expansion inside ":+" expansion?

[YKdvd]

The following example of parameter expansion within another expansion works in bash (Ubuntu and MacOS, also zsh on the latter):

export FAKE_PATH=
echo ${FAKE_PATH:+${FAKE_PATH};}/mongoose
export FAKE_PATH=/wombat
echo ${FAKE_PATH:+${FAKE_PATH};}/mongoose

The intent is to only append the ";" character if "FAKE_BATH" is already set, to avoid getting ";/mongoose" when it isn't. The result is as expected:

/mongoose
/wombat;/mongoose

But Python (3.9) code that should be the equivalent for parameter_expansion:

from parameter_expansion import expand
s= r"${FAKE_PATH:+${FAKE_PATH};}/mongoose"
#print(s)
env = {}
result = expand(s, environ=env)
print("%s"%(result))
env["FAKE_PATH"] = "/wombat"
result = expand(s, environ=private)
print("%s"%(result))

fails, and produces:

;}/mongoose
//mongoose

If I change the passed environment to the second call to env["FAKE_PATH"] = "_wombat"
the output is appears correct:
_wombat/mongoose
the leading "/" in the existing FAKE_PATH variable appears to be one problem, although of course the problem with the first variant must be something else. I'm guessing the parser can't handle this otherwise bash-acceptable syntax with an expansion inside an ":+" expansion like this? I didn't see anything quite like it in the test cases. I know the docs warn "All the standard shell expansions are supported, including some level of nested expansion, as long as this is not too complex or ambiguous", but it is unfortunate that this syntax fails.

[pombredanne]

Thank you for this report!
This feels at first like a not-yet-supported case of nested parameters expansion.

For reference:

>>> import os
>>> from parameter_expansion import expand
>>> s= "${FAKE_PATH:+${FAKE_PATH};}/mongoose"
>>> expand(s, env={})
'/mongoose'
>>> expand(s, env={"FAKE_PATH": "/wombat"})
'//mongoose'
>>> expand(s, env={"FAKE_PATH": "wombat"})
'wombat/mongoose'

Note that in any case I am not sure why you were using a raw string in your example

[YKdvd]

I was probably testing the example with a Windows path that uses \ backslashes, and the r"" was left from that - raw strings are handy for that to avoid doubling the backslashes to escape them.