Suite package: what would you want in a redesigned suite?

[fredbi]

Context

When we forked stretchr/testify into go-openapi/testify/v2, we removed the suite package along with mock. The reasons were
primarily about technical debt:

• Heavy use of reflection for test discovery and lifecycle management
• Tight coupling between the suite runner and the testing package internals
• Complex inheritance-like patterns that don't fit well with Go idioms
• Maintenance burden disproportionate to the value delivered

That said, we recognize that suites solve a real problem. Setup/teardown lifecycle management matters, especially for
integration tests that need database connections, HTTP servers, temporary files, or other shared resources.

What we're not bringing back

The old suite.Suite struct with its reflection-based test discovery and Run method. That design carried most of the debt.

What we're open to exploring

A lightweight, modern approach that:

• Works with testing.T rather than wrapping it
• Uses explicit interfaces or function signatures instead of reflection-based method discovery
• Plays well with t.Parallel(), t.Cleanup(), and other modern testing idioms
• Stays true to our zero-external-dependency principle
• Is easy to understand — no hidden magic

We don't have a design yet, and that's intentional. We'd rather hear from you first.

What we'd like to know

• Do you use suites today? If so, what for? (integration tests, unit test grouping, shared fixtures, something else?)
• What do you actually need from a suite? Setup/teardown per suite? Per test? Both?
• What frustrated you about the old suite package?
• Would a simpler alternative work? For example, a helper that manages t.Cleanup() registration for shared resources — without
  the full suite ceremony.
• Are there patterns from other ecosystems (or your own codebase) that you think we should look at?

No promises on timeline or scope. We want to understand the demand and the shape of the problem before committing to anything.