Nop. But you can customise the engine to do whatever experiment you may want. The file to modify that selectively setups FXAA or TSR is this one: https://github.com/EpicGames/UnrealEngine/blob/ue5-main/Engine/Source/Runtime/Renderer/Private/PostProcess/PostProcessing.cpp
Is there any way to get access to the Z buffer values inside the TSRUpdateHistory.usf like in TemporalAA.usf ?
No and there is no need for it in the current algorithms that works with parallax mask instead generated the DecimateHistory pass. This saves memory bandwidth as this only 1byte per rendering pixel instead of 4byte which is important to have in mind to save memory bandwidth available for the previous frame’s history reprojection in the UpdateHistory pass.
But nothing prevents you to customise FTSRUpdateHistoryCS::FParameters to add a SHADER_PARAMETER_RDG_TEXTURE() for the depht buffer for your need.
Some projectils leave a trail of a rough area behind, until it gets smoothed out, other times like during character walking (or in any case, where the flipbook switches to a new sprite to play an animation) you have noticeable artifacts around that flipbook/sprite.
Rough area behind is due to completly discarding the details and needing to reaccumulate. This is where the idea of the TSR history resurection explained earlier should help ( TSR feedback thread - #3 by Guillaume.Abadie )
Another one where artifacts are quite visible around the character:
You are talking about the motion blur arround the character? I don’t see anything obviously wrong from TSR on this.
Edit: here a multi-directional test-char amde with masked flipbooks, where it becomes really visible. The shadows from those balls and the balls themselves become quite a mess during moving and rotation:
Yeah fast moving shadows is known problem ( Unreal Engine Issues and Bug Tracker (UE-182858) ), the r.TSR.ShadingRejection.Flickering heuristic used on high and Epic anti-aliasing scalability thinks it’s a pixel becoming unstable like moire pattern and try to stabilize it a bit. You should be able to lower r.TSR.ShadingRejection.Flickering.Period in your Project’s Config/DefaultEngine.ini to lower it (or even disable completly as I doubt your content will have a lot of moire generated patterns).
So SceneCaptures that are not with a Capture Source of Final Color typically do not have the smudging/ghosting effects.
That might because Final Color is the one that has the processing chain where TAA/TSR or otehr third party temporal upscalers are. 
While looking through some of the dumpgpu output, I do see some of the velocity passes seemingly split in data (one has a moving model fully split down the middle). Unsure if that’s just a quirk of the command output or a legitimate issue.
That sounds like an interesting find.