This is just based on my experience, not technical knowledge
1) I really don't think you have to worry about this, i've never had any trouble with this. If you open multiple groups at once keys with the same value will be processed the same, so if you want to use two keys from different groups that have the same key value, you'll have to read the groups separately. But i don't think you need to bother resetting the key port (i never do).
2) Again, i don't put any delay in between reading and writing and haven't ever noticed any problems on actual hardware (83+, 83+SE, and 84+SE). I've heard people say this before, but i've never actually bothered with it and haven't noticed any side effects.
3) I dunno this one, sorry. I just know of the onInterrupt flag "   OnInterrupt,(IY+onFlags)"

Yay, an actual question about assembly! (I love answering these)

1. You do not need to reset the port back to $FF. I know at one point I had trouble with this, but that was ages ago (I don't think I was timing it right)

2. You absolutely do need a delay. At 6.5 MHz, you might be able to sneak by every now and then, but honestly, just throw a "ld a, (de)" between your out and your in. It's only 1 byte and gives you 7 t-states. For 15MHz, you'll need more than that. I've historically used 16 t-states for 15MHz so to keep with the optimized delays, you might want to do a "push af \ pop af" or something.

3. Simple, bit 3 of port 4. (WikiTi)

For the delay, do you mean the delay between writing to select a group and reading the result? At 6MHz, 8 cycles has always always been the traditional safe delay to put between out (1),a and in a,(1), although some implementations have been known to use 7 cycles. At 15MHz, I think the 16 cycles that thepenguin77 has suggested is not enough; Axe used to use 22 cycles and certain people reported that their calculators had issues even with that. I'm not sure of the exact number, but to be safe I'd go with at least 32 cycles or so of delay, if not more. An extra few cycles in a routine like this won't hurt overall performance anyways.

I have never bothered with "resetting" the key port. Here's the new MicrOS GetCSC clone. The delay is 29 cycles.
;------ GetCSC -----------------------------------------------------------------
RawGetCSC:
; Scans the keyboard matrix for any pressed key, returning the first it finds,
; or 0 if none.
; Inputs:
;  - None
; Output:
;  - Code in A, or 0 if none
; Destroys:
;  - BC
ld bc, 07BFh
_: ; Matrix scan loop
ld a, c
out (pKey), a
rrca
ld c, a
pop af ; Probably should waste at least 20 cycles here.
push af ; This is legal because F actually does have 8 bits in it.
in a, (pKey)
cp 0ffh
jr nz, +_ ; Any key pressed?
djnz -_
; No keys pressed in any key group, so return 0.
xor a
ret
_: ; Yay! Found a key, now form a scan code
dec b
sla b
sla b
sla b
; Get which bit in A is reset
ld c, 0
_: rrca
inc c
jr c, -_
ld a, c
or b
ret