Annoyance wrt ref@{1} and reflog expiry

I have been disturbed by this for a long time, but not strongly enough to do anything to it.

This sequence works

    $ git checkout -b newbranch
    $ git commit --allow-empty -m one
    $ git show -s newbranch@{1}

and shows the state that was immediately after the newbranch was created.

But then if you do

    $ git reflog expire --expire=now refs/heads/newbranch
    $ git commit --allow=empty -m two
    $ git show -s newbranch@{1}

you'd be scolded with

    fatal: log for 'newbranch' only has 1 entries

While it is true that it has only 1 entry, we have enough information in that single entry that records the transition between the state in which the tip of the branch was pointing at commit 'one' to the new commit 'two' built on it, so we should be able to answer "what object newbranch was pointing at?". But we refuse to do so.

And it is unintuitive. It is understandable to the users that all the ref history before "reflog expire" is lost---it was what the end user asked Git to do. But after creating one commit on the state (or do anything else that moves the ref) and finding it regrettable, "git reset --hard @{1}" should be a viable way to recover from the mistake made _after_ the reflog entries were expired.

Opinions?