Et éventuellement on souhaite remplacer complètement pipenv par poetry?

J'aurais tendance à dire que oui.

Mon impression est que Poetry est supérieur à Pipenv.

Déjà, ça fait deux ou trois fois que j'ai du mal à résoudre l'arbre des dépendances avec Pipenv et qu'avec Poetry je réussi à peu près immédiatement. Les messages lors d'incompatibilités sont beaucoup plus clairs.
Il y a aussi de petites options qui permettent de cibler directement l'ensemble des librairies qui utilisent une dépendance spécifique (ex.: poetry show --tree --why six pour savoir qui utilise six). C'est peut-être aussi possible avec Pipenv, mais je n'ai pas vu comment le faire de façon aussi simple.
Le fichier poetry.lock est aussi plus lisible que le Pipefile.lock.
Il offre aussi la possibilité de packager les projets. Ce qui simplifiera la vie le jour où l'on voudrait que certains projets soient disponible sous forme de librairies.
Il permet aussi de couvrir des ranges de versions de Python. Ce qui serait un avantage encore une fois advenant l'utilisation sous forme de librairie pour d'autres projets.

Cela dit, les workflows pourront gérer les deux, je ne vois pas d'obligation pour tout changer vers Poetry.
On peut aussi voir à l'usage, si mon impression par rapport à Poetry se valide dans la réalité.

J'ai updaté la PR pour offrir en output la chaîne 'pipenv' ou 'poetry'.