Does anyone like CloneKeys() []K, CloneValues() []V?

I'm not sure I'm not bike-shedding, but Clone might communicate the allocation of the returned slice, and the shallow copy semantics. slices uses Clone to mean shallow copy.

Does anyone like CloneKeys() []K, CloneValues() []V?

It does not feel necessary. It's (almost) obvious that a map type object does not have its key and values in slices.

#61900 adds Keys and Values back as iterators.
#61899 adds slices.Collect and slices.Sorted.

With these, the old maps.Keys(m) would become slices.Collect(maps.Keys(m)) and similarly Values.
Better, this idiom:

keys := maps.Keys(m)
slices.Sort(keys)
use(keys)

becomes

use(slices.Sorted(maps.Keys(m))

Are there other pattern uses for maps.Keys (other than sorting them) that we should be sure to cover?

Just my 2¢, but yeah, I feel like as long as slices.Sorted gets added, the uses of maps.KeySlice are infrequent enough that it could just be keys := slices.Append(make([]K,0, len(m)), maps.Keys(m)) those times when you need it.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Are there other pattern uses for maps.Keys (other than sorting them) that we should be sure to cover?

I suppose creating a set of them using a map[K]struct{}.

You could do that with an iterator and InsertInto.

Finishing this proposal discussion is blocked on #61405.

Change https://go.dev/cl/535215 mentions this issue: runtime: use real type size in map keys and values functions

The key issue seems to be #61626 (comment).
It sounds like if we add maps.Keys, maps.Values, and slices.Collect, then we can use

KeySlices(m) => slices.Collect(maps.Keys(m)) (or slices.Sorted(maps.Keys(m)))
ValuesSlice(m) => slices.Collect(maps.Values(m))

and do not need to add these explicitly.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

and do not need to add these explicitly.

Need, no. Make devs life easier and Go more approachable yes.

I feel like the issue is #61900 (comment). I agree it's more elegant to write a single line instead of three, but I don't mind writing those extra lines for the sake of optimization.

I think it’s a little too soon to permanently decline these. I think we definitely can skip them for now, but it may be that after a few years of experience there turns out to be some reason they are needed after all and this can be reopened then.

@Nasfame See also #61900.

I think it’s a little too soon to permanently decline these.

Decline is never permanent. Only accept is permanent.

No change in consensus, so declined.
— rsc for the proposal review group