Random idea: take inspiration from http4s `Headers`?

Just a random idea I've been brewing, feel free to tell me I'm being dumb

It seems to me a lot of the trickiness with scalacOptions is that in userland we want to operate (add/remove) with a higher-level DSL (which is what this library provides) but the underlying representation is a raw Seq[String].

I assume this has motivated the approach in sbt-tpolecat where tpolecatScalacOptions is defined in terms of the DSL and it is intended that all operations are done on that setting, and the plugin then writes it into scalacOptions. Unfortunately this has shortcomings as well e.g. https://github.com/typelevel/sbt-tpolecat/issues/60 or https://github.com/typelevel/sbt-tpolecat/issues/102.

While reviewing an http4s PR I realized that the Headers model is super similar to maybe what we want here. Notably, Headers is represented as a raw sequence of CIString -> String tuples but users are able to interact with it elegantly using the various model classes. I wonder if we could adopt a similar design pattern here.

I haven't fully worked out how it would actually work in sbt, but the rough idea would be that all interactions should be done by applying DSL-based operations directly to the scalacOptions setting. I think this would get us the wins while avoiding the traps.

Thoughts?

Start by reviewing the current scalacOptions interactions, the sbt-tpolecat limitations in issues 60 and 102, and the http4s Headers model mentioned in the discussion. The issue does not name files, tests, an entry point, or concrete acceptance criteria, so the desired design and definition of done need to be established first.