It is easy to fix, 2.5 combinators and 1 tick solution will be ready.
Why do you leave us hanging like that?

This is what I came up with for a minimal 1 tick update, 1 tick delay solution:
tmp.png
Input: A (top left), output X (right)
bot left: -1 -> X,
top right: X > A -> X
bot right: @ > X ...

Just ran into this while working with the console, but can't reproduce right now.

I had it wrong with the other rail types: diagonal straight rail is also affected: here I can't even find coordinates for which find_entity returns anything.

I'm creating curved rail at {0,0} facing north using the game or

game.player.surface.create_entity({name="curved-rail", position={0,0}, direction=0})

but then `find_entity` used like this

game.player.surface.find_entity("curved-rail", {0,0})

only gives me nil back.

I verified that the rail ...

When you build it by script you can manually set it to 2 additional valid directions that the standard rotate-manually cycle doesn't hit but are valid. Why you'd ever want those directions I don't know - it doesn't effect the state of the rail - but you can use them if you like.

This is correct ...

So the non-intuitive direction on diagonal rail seems to be intentional but there is still the weirdness of not having the same behaviour as the manual build mode:
Using create_entity at {0.5,0.5} with directions 3 and 7 will create two distinct rails, while in manual mode the rail-tile doesn't get ...

Same thing at {1,1} (which {0,0} probably snaps to). It is a fact, that the API doesn't behave the same way as manual building does.
Manually building at {0.5,0.5} and rotating in hand doesn't change the Position, but using the API at {0.5,0.5} with directions 3 and 7 creates two rail tiles on ...

Running

game.local_player.surface.create_entity({name="straight-rail", position={0,0}, direction=defines.direction.northeast})

will create a diagonal straight-rail facing in the wrong/non-intuitive direction (compare to north/south and east/west).

Additionally diagonal rails seem to allow four ...

I tried to optimize the sorter design for one belt of full density and with proper output side-balancing.
The first version without backlog protection has full throughput and is probably about as compact as it gets (fits within 9x4).
The second version with backlog protection is quite a bit larger ...