I get what you're saying and agreed that does sound like a good, user-friendly design.
To give you a slightly different perspective, here's what our Ticket Status topic does: we have Ticket as a pattern entity and at the top of the topic, we do a simple regex check on the user's utterance - vaSystem.getSearchText().match(/(ritm|inc|ims)[0-9]{7,12}/i (note: this regex exactly matches the entity's regex) - and if there's no match, we ask the user how they'd like to search for a ticket: search by number, show all open tickets, show all closed tickets, etc. And if there is a match, then we bypass that first question and assume they want to search by number, in which case the topic points to the text input ("Enter your ticket number") which is mapped to the entity, skip confirmation if matched, and voila - that's it, the user is shown the status of that ticket without having to type it in or provide any other input. Plus it works for users that know their ticket number but don't input it as an utterance.
If there was a more ootb way to get the entity in the topic, I would certainly prefer to use it, but luckily for now, ticket number being a pattern entity makes it easy enough to run the same regex on the utterance.
And so my recommendation would be to not overthink the entity extraction part - use the ootb entity input mapping - and do something similar to what I did: regex at the beginning of the topic to bypass the normal flow for users that provided a ticket number and send them to a text input mapped to your ticket entity and check the "Enable NLU at Input Node" and "Skip confirmation for recognized entity" boxes. If you keep your topic design as described, it will be as if that text input doesn't exist - no user will ever see it because the only time it'll be reached is when there's an entity match and it'll just auto-fill for the user.
