Proposal: Renaming this library

I often talk to colleagues who use cats-core, cats-effect, etc... but know nothing about mouse.
This is sad because I love mouse and all its features ( which prevents the usage of EitherT and OptionT for instance) , but I see the reasons why this can't be merged within cats-core.

However, I wonder if there is a way to improve the visibility of this project.
With the arrival of Scala 3 we can take the opportunity to rename/fork this library to a better and clearer name which includes cats- as prefix to let it be more part of an ecosystem. I see cats-core as the base, mouse as an advanced syntax of cats and cats-effect as the effects system.
At the moment, mouse seems an independent library and not a cats ecosystem add-on to me.

I don't want to blame the current name, I just wonder if a rebranding would improve the visibility of this library which, in my humble opinion, should be part of every cats-based project. Too many times I have seen boilerplate and operators that are already part of mouse rewritten within Utils classes.

Going deeper, the problem I see with the mouse name is that it doesn't really describe the purpose of the library, which aim to just enrich cats with a nice and useful syntax without adding new type classes or features.

Some ideas:

• cats-pragmatics (polished, but I'm not sure if it is correct)
• cats-mouse ( more conservative )
• cats-suit / cats-dress ( fancy and funny but I don't know how explanatory it is )
• cats-enrichments / cats-rich-syntax ( more serious but clear )

Something like this, for instance:

"org.typelevel" %% "cats-core" % "x.y.z",
"org.typelevel" %% "cats-rich-syntax" % "x.y.z",
"org.typelevel" %% "cats-effect" % "x.y.z",

Once done with the name, I'd also rethink the packages because it would be nice to try to keep the same pattern as cats-core in order to simplify the life of the users.
Since mouse adds syntax to cats core, maybe it is correct to put it under cats.syntax package, where mouse is a specialization of the basic cats syntax. This creates a kind of boundary.

Moreover, this is also useful to better organize imports with Scalafmt

rewrite.rules = [ SortImports ]

Example

// current 
import cats.syntax.all.* // imports all cats-core syntax
import mouse.all.* // import all mouse syntax

// new
import cats.syntax.all.* // imports all cats-core syntax
import cats.syntax.rich.all.* // import all cats rich syntax

We could also consider to no having a global import but split them by type as suggested in #362 which I like TBH

import cats.syntax.collections.* // import all cats boxed syntax
import cats.syntax.nested.* // import all cats nested syntax

//or 
import cats.syntax.rich.collections.* // import all cats boxed syntax
import cats.syntax.rich.nested.* // import all cats nested syntax

To rename or not, what name and how to do it is up to you, but I just wanted to sow a seed for a discussion.
Maybe I am the only one who sees this problem.

Let me know what you think :)

Start by reviewing the naming, package, import, and artifact-coordinate proposals in this issue, along with the related discussion in #362. Done would require an agreed name and migration approach before any repository changes can be scoped.