C# / .NET has always had that abililty.

  <EmbeddedResource Include="/path/to/file.txt" /> 

Then you can read that file from the assembly with:

  assembly.GetManifestResourceStream

I'm not sure what's awkward about that, but it's nothing new.

Discoverability for this is in visual studio, if you go to file properties there's a drop-down where you choose between Content, EmbeddedResource, Ignore, etc.

That determines what happens in compile, whether it is copied to output directory, compiled into the binary, etc.

The Stream is awkward. It needs to be processed either once at startup or lazy on access, or every time it's used (allocations!). Also discovering multiple files is awkward.

Can't you already do that with embedded resources?

Yes, you can. But it's a bit cumbersome. The API to read them is not really intuitive, they are only accessible as a Stream, so they need to be either read every time into a string (new allocation, slow), or you need a helper that reads them once and keeps them in memory. I think there are also a lot of gotchas around naming and listing them.

In modern code I don't see them that often anymore.

I see your point and I don't necessarily disagree but better API for embedded resources is just a couple of simple extension methods away. I wouldn't even bother adding an external package for it.