It would be nice if also other parts of modularity [1] were adjusted to benefit from this.

+1.

How about suggesting both? For single package modules, just a version may be okay.
I think it is hard to have a general solution for this - it is a recommendation as you say.
Maybe best practice for different ecosystems needs to be documented though?

(It is a pity that there are so few languages that have a distro.)

<prefix><module-name>-<module-stream>-<module-context> would be a perfect branch naming schema, because with the new modularity static contexts, NSC represents a virtual repo.

Because multi-context streams are quite rare in Fedora and as long sources are identical and only the binaries of the modules differ, using the following schema might be more reasonable: <prefix><module-name>-<module-stream>

Prefix could be stream- or module- or anything else that makes sense within the distro's branching policy.

Nobody prevents you from using that scheme in your rpms-namespace branches. If you like them, use them. The naming-policy https://docs.fedoraproject.org/en-US/modularity/policies/naming-guidelines/#_package_branch_name only recommends upstream versions. It does not mandate them.

I'm not fond of making the format mandatory because it cannot cater all use cases. For example in Perl modules, we frequently share the same RPM branch among multiple modules for build-only packages. Or we reuse non-modular branches as compensations for no default streams. One module-stream identifier cannot fit them all.

This is statistics for component refs from F36 modular repository:

# zcat /var/cache/dnf/fedora-modular-f440a08391e7b71d/repodata/9f72cb0ffbf4e7c96979c0f391c1a6b7ddeabb4c0d7288b7ffc2d4c3b794b3e3-modules.yaml.gz | grep ref: |sort | uniq -c | sort -n -r
    115         ref: f33
     56         ref: f34
     14         ref: rawhide
      5         ref: stream-postgresql-11
      3         ref: 1.22
      3         ref: stream-postgresql-12
      2         ref: 1.21
      2         ref: 1.20
      2         ref: 1
      2         ref: stream-6.0
      2         ref: latest
      1         ref: 9.2
      1         ref: 82lts
      1         ref: 81249e56
      1         ref: 8.10
      1         ref: 6.2
      1         ref: 6.1
      1         ref: 6.0
      1         ref: 4.0
      1         ref: 16
      1         ref: 14
      1         ref: 1.23
      1         ref: 1.14
      1         ref: 10.7
      1         ref: 10.6
      1         ref: 10.5
      1         ref: stream-1.20
      1         ref: stream-postgresql-14
      1         ref: stream-postgresql-10
      1         ref: stream-mainline
      1         ref: nextcloud-22
      1         ref: nextcloud-21
      1         ref: nextcloud-19
      1         ref: nextcloud-18
      1         ref: nextcloud-stable
      1         ref: mariadb-10.7
      1         ref: mariadb-10.6
      1         ref: mariadb-10.5

I'm NOT against mentioning (stream-)module-stream schema as a popular one in the guidelines, but I do not want make it obligatory.

I think the proposal is using "should" and "recommended" wording, which allows exceptions IMO.

BTW, your example demonstrates quite nicely why the recommended scheme should be updated, because where it is quite nicely visible what "stream-postgresql-10" means, you might just guess what the "latest" is about. Again, this might be reasonable exception, but we should aim to make the stream branches more self describing.