Here's screen recording illustrating my situation.

Works just fine for me. Maybe try a File->Defaults->Load Factory Settings

Ubuntu 18.04 build: 2.82 (sub 1) 2019-11-20 21:25 ba1e9ae4733a Debug
Geforce 1080 driver version 4.5.0 NVIDIA 440.26

With a sphere 2.80 behaves exactly the same.

Update: I've determined that this bug occurs only if the two objects have completely overlapping vertices, regardless of point count with the surface constraint set to its default value, which is the "On Surface" option.

No-one in that thread stated it was an already reported issue - only that after testing for this issue in 2.8, they discovered 2.8's behaviour is the same. Did you search for an existing bug report? I did, and I could not find it.

At any rate, I can confirm that in this case the identical position prevents the shrinkwrap modifier from working properly. Only by translating one of the two objects to another position will the modifier function.

Yeah I see now you are talking about if mesh verts are already EXACTLY matching the shrinkwrap target then offset doesn't work on those verts. It does work I think if you set snap mode to above surface though.

I also checked 2.79b and it works the same way, you have to check above surface if verts exactly match.

I did some more testing. The bug is triggered by more than just an identical position:

Add a sphere, and a plane. Both occupy and share the exact same coordinates. Assign a shrinkwrap modifier to the sphere, and use the plane as a target.
Result: works as expected.

It this issue was caused by merely the two objects sharing the identical positional values, this scenario would fail. But it does not.

Repeat the steps as the OP demonstrates in the posted video. Scale-up the shell. Or rotate the object by a degree.
Result: the modifier functions as expected.

This proves both objects may share the same coordinates, and a simple transform (scale) fixes the issue. It disproves that the position is the culprit. Something else is the cause.

Repeat all the steps of the video, and change the origin’s position.
Result: no effect.

If the origin is somehow causing the issue, it would have the same effect as a positional translation. It does not.

repeat the same steps again, and this time enter edit mode and rotate the mesh shell a couple of degrees .
Result: the modifier works.

This is a telling test, because it should have failed IF the issue is directly related to the object’s position.
Instead, it seems to point at an issue with the vertices being in the exact same position.

Repeat the same steps once more, and edit the mesh of the shell. Select a single vertex, and move it.
Result: the modifier affects the single vertex, but other vertices remain unaffected.

All in all, the underlying cause seems to be the vertices identical position of both objects. Use a different mesh, and it will work. Transform the shell mesh, either in object or mesh mode, and it will work.

ONLY when the two objects’ vertices share the identical positions will the shrinkwrap modifier fail to function.

In T71749#814785, @Herbert van der Wegen (herbert123) wrote:

No-one in that thread stated it was an already reported issue - only that after testing for this issue in 2.8, they discovered 2.8's behaviour is the same. Did you search for an existing bug report? I did, and I could not find it.

At any rate, I can confirm that in this case the identical position prevents the shrinkwrap modifier from working properly. Only by translating one of the two objects to another position will the modifier function.

No, I couldn't find it either. I edited my previous comment.

Anthony is correct: it works just like 2.79 and previous versions when the Project mode is set to Above Surface.

I wonder at this point if this is a bug at all, and rather intended behaviour. I also discovered that use cases exist in which this behaviour creates interesting effects when the a number of vertices of either object mesh are randomly translated or the mesh is subdivided.

I am unsure if this should be "fixed", or is an actual bug.