Comment 3 for bug 635855

(aside)
Nested lua expansions actually "work" @rpm5.org.

Here's your foo.spec with %trace added:
  0< # this statement stumbles (print buffer is mis-directed)
  1> %{expand:%{lua:
  foo = rpm.expand("%__foo")
  print("BuildRequires: " .. foo .. "-devel" .. "\n")
}}^
  2> %{lua:
  foo = rpm.expand("%__foo")
  print("BuildRequires: " .. foo .. "-devel" .. "\n")
}^
  1> %__foo^
  2> %{lua:
  print("foo")
}^
  1< foo
  0< foo
  1< BuildRequires: foo-devel
  1< BuildRequires: foo-devel
  0< BuildRequires: foo-devel

But the fundamental issue for RPM is
    Is there any need for multiple nested lua invocations in RPM
    coordinated through a print buffer?

E.g. the embedded lua interpreter is (by intent) persistent so that
variables can be shared between invocations.

OTOH, the expectation here is that the print buffer be specifcally tied
to each nested invocation, i.e. unshared. That isn't a suprising expectation,
just not what was/is implemented with embedded lua.

Its conceivable to have lua invocations behave either with globally
shared state, or with independent nested invocations, dependent
on how invoked. The analogue in shell is {} vs () nesting, commands within
{} are executed by the current interpreter, () nests an interpreter when needed.

But that just brings me full circle to
    Is there really any need for this level of complexity to generate
        BuildRequires: foo-devel