This issue has been open for several months now without an update and I'd like to encourage its resolution. The upstream doas project is still getting issue reports [1] which are resulting from confusion in the naming between "doas" versus "OpenDoas". Ideally this package should have its name changed or point to the upstream corresponding with the package name.
I'd also like to respond to the post linked to by Andrea Pappacoda in the previous comment if I may. I have two thoughts on that. One is that the bugs reported as concerns were fixed and aren't relevant anymore and were handled before this Debian bug report was filed. I thin it should be considered out of date. The other is that one of the supposed flaws reported was incorrect (due to a misunderstanding on the filer's part on how UIDs were handled by doas) and, when this was explained to the person filing the issue they went on a misinformation and harassment campaign across multiple social media platforms against the slicer69/doas port. Blog posts like the one linked to above about "slicer69-doas" were the result and based on the misunderstanding of security issues by the original person filing the bug report. I'm not saying there weren't bug issues during the porting process, just that some of them which were (in the above post's words "treated superficially") were actually dismissed for being incorrect or not what the issue reporter claimed. None of them were particular serious either as they'd require root access to exploit. This may not be entirely relevant to the decision on how to name Debian packages, but I wanted to clear the record as I feel the article linked to by Pappacoda isn't representative of the real situation in terms of doas vs OpenDoas. Both projects are good at what they do and both have had some flaws fixed. I don't think one should be considered "better" or "more of a true doas" over the other. But I do think Debian's naming approach should reflect upstream to avoid confusion. I do agree with Pappacoda that having Debian "doas" be a virtual package with "opendoas" and "doas-portable" being the underlying real packages makes sense. 1. https://github.com/slicer69/doas/pull/99
