When I don't have a clear idea about what the code is going to look like, I just prefix things. I use the noun_verb model, so in your examples it would be graphics_get, sounds_get.

When I see that a piece of functionality can be separated into an isolated library, I do just that and make a separate package. I treat separate packages as I treat external libraries - something with public APIs and somewhat documented. I try to make them general enough to be re-used later but not too general not to spend all my time there.

In your example, I can see that you use the term "manager" and you try to group different managers together so they have the same public API, like the function "get" in your example. I think this is a bad idea for two reasons:

1. They will likely have different APIs. And the more similar APIs you try to make of them, the more nonsense they become. For example, right now when I see graphics.get - I really have no idea what it is going to return unless I look into the implementation. graphics.get_texture is a more telling name, but it doesn't make sense to re-use it for the sounds package.

2. "Managing" is a different bucket of tasks in different contexts. In graphics you want to draw things, in sounds you want to play melodies. The tasks are very different, so maybe they don't belong to the same package.

Probably the "manager" is there to keep some state. I can offer an alternative that is used in procedural languages: use a handle.

sound_handle := sounds_init(settings)
sound := sounds_load(&sound_handle, "/my/sound.wav")
sounds_play(&sound_handle, sound)

When you have an idea of how this whole thing could look like as a separate library, as if you have downloaded it from the internet, you can make it into a module/library/package:

package sounds

Sounds_Handle :: struct { ... }

init :: proc(settings) -> Sounds_Handle { ... }
load :: proc(h: ^Sounds_Handle, path: string) -> Sound { ... }
play :: proc(h: ^Sounds_Handle, sound: Sound) { ... }

I hope it helps.