Package option processing differs between loadPackage and load

This issue was triaged from bugs/dan/0-newPackage, 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

options processing depends on whether loadPackage is used, which is unfortunate:

    i1 : loadPackage "Foo"
    OptionTable

    o1 = Foo

    o1 : Package

    i3 : load "Foo.m2"
    List

    i4 : get "Foo.m2"

    o4 = newPackage ( "Foo", Configuration => {} )
	 print class (options Foo).Configuration

Where it stands today

Reproduces exactly. The same package option comes back as a different type depending on how the
package was loaded:

i1 : loadPackage "Foo"; class (options Foo).Configuration
o1 = OptionTable

i2 : load "Foo.m2";     class (options Foo).Configuration
o2 = List

Why it matters

Package code that reads its own Configuration has to cope with both, or work only under one of the
two loading paths. Since load is what happens when a developer is iterating on a package file
directly, the difference shows up exactly when someone is debugging.

Notes for whoever picks this up

The asymmetry is in who processes the options: loadPackage passes them through the option-processing
machinery that turns the list into an OptionTable, while a bare load evaluates the newPackage
call with whatever the author wrote — a List. Normalizing inside newPackage itself, rather than in
loadPackage, would make the two agree regardless of entry point.

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

Reproduce the difference using the issue's loadPackage and load examples, then trace how each path reaches newPackage and processes Configuration. Normalize the option handling at the shared entry point so both paths produce the same type, and verify that class (options Foo).Configuration agrees after loading through either path.