@falsifian thanks for reporting the error which i can reproduce with last cabal-3.4.0.0
Points to consider:

• cabal v2-build lets you build packages which .cabal file name differs from the package name described in that file (it is any difference ,not only between - and _)
• but cabal install generates a package.tar distribution file and then uses it to install the package like it would downloaded it from hackage. This install from a tar file needs that the .cabal file name matches exactly the package name, so it fails
• that means the package will not be able to be uploaded to hackage as cabal check tell us:

PS D:\dev\ws\haskell\cabal-test> cabal check
Warning: The filename .\cabal_test.cabal does not match package name
(expected: cabal-test.cabal)
Warning: Hackage would reject this package.

So we could do:

• Convert the warning in cabal check in an error for cabal install and cabal build
• Fix cabal install to match the behaviour of cabal build and not throw an error only for local tars generated by cabal install itself, i guess it will be tricky
• Throw an error in cabal install using the same code cabal check uses to print the warning

Imo the build and install behaviour should be coherent and throw an error, but if it is already a warning is cause someone would be using .cabal names different from package names locally (???).
So i would vote for 2, although 3 will be easier to implement i guess

@jneira Thanks for the analysis. I don't have strong opinions or intimate knowledge of cabal, so I'll leave the discussion to others here and in #6299. I've learned the lesson already, so it's not a problem for me unless I forget :)

As a easier to do improvement, we could improve the actual error message, without touching actual semantics

While my intention was primarily to improve the workflow with name-agnostic Cabal files (e.g. package.cabal regardless of the actual package name), I accidentally implemented a fix for this in #10947:
There, the Cabal file is renamed to PACKAGE_NAME.cabal in the source distribution archive.

Would this be an acceptable solution at all? If so, then there a some open questions regarding the approach:

1. The main concern, as pointed out by @ulysses4ever , is whether this breaks existing workflows or not. What are the options to mitigate that?
2. Should the changed behaviour hidden behind a feature flag? Alternatively: Should there be an option to restore the old behaviour?
3. Should there be a warning when the renaming happens?