gens of a ring made by toField returns the empty list

This issue was triaged from bugs/dan/0.9-toField, one of the 857 files removed from the pre-GitHub bugs/ tree by d2c8d27826 and catalogued in #36. The commentary below was written by Claude (Claude Opus 5, via Claude Code), not by @d-torrance, whose account posted it -- please weigh it accordingly.

The original file, verbatim

It would be nice if the rings made by toField belonged to a new class "Field", so they don't look like polynomial rings.

In line with that, it would be nice if newRing would return a ring that had the
old ring as a base ring (somehow) so that promotion, etc, would work.

Indeed, extending promotion to the entire tree of rings made from others, even
if not supported by fast routines in the engine, would be good for usability.


---

Kahle, in particular, would like results of toField to still have a list of generators obtainable with "gens".

See also test/fieldgens.m2

Where it stands today

None of the file's three asks is met, and the middle one is worse than unimplemented.

A Field class. toField still returns a PolynomialRing, so a ring the user has declared to be a
field continues to look like a polynomial ring to every method that dispatches on class.

Generators. gens of a toFielded ring gives {}, where gens of the same quotient before
toField gives {x}. So the operation silently loses information rather than merely failing to gain a
class.

Promotion across derived rings. Unchanged: a ring built by newRing does not carry the old ring as
a base, so promotion between them does not work.

Why the class question is not cosmetic

isField, factorization and the factory interface all decide what they can do by looking at the ring's
class or its shape. toField's promise — "treat this as a field" — is currently invisible to them,
which is the root of a family of downstream failures: #1660 (toField prevents getting the right
kernel of a ring map) and #3973 are both open, and neither is this file's request.

Related, from the engine side: the factory interface accepts only ZZ/n, ZZ, QQ or GF as
coefficient rings — visible in the error text quoted in #3173 — so a toFielded quotient has no
representation there whatever its class.

_{open · disposition issue · source of truth: bug-triage/catalog.tsv}

Start with test/fieldgens.m2 and the toField and gens behavior described in the issue. Compare generators before and after toField, then determine how the requested Field classification and newRing promotion behavior relate to that failure. Done requires an agreed scope and tests covering the intended generator and derived-ring behavior.