If we could get some stateless entry points, then it's possible to build a router, but even menu entries have some states.
When menu is build we call static menu methods, and they can do some logic like authorization or pass some parameters to the called functions. All of these parameters are stored in the session and if link is clicked we know what to call and what are the parameters for the function.
The same logic applies to the callback hrefs (like going to contact from the company view), but its way more complicated, because EPESI recreates a state and renders the same view as it was before the link was clicked (Company view in this case) and during the link creation (again) now it knows that this link has been clicked and it calls this method with supplied parameters. Here is a clue for some laggy responses of the EPESI. It's a known drawback, but it's easy to use.
Why it's a drawback? Suppose you'll use the long lasting search query (e.g. quick search in the upper right corner). It lasts 10 seconds to search through the database. When you'll click on the contact to open it, then search is performed once again (because view is recreated), until it'll reach desired contact.
If we would like do the router, then we had to store all session variables to recreate a state, but if this link is going to be the same across different users (eg. user A want to give a link to the user B), then we don't know is it safe to store and recreate a session variables for the other user.
We'd like to rewrite EPESI to use the same DB schema and data files, but totally different PHP code. It's a hard work and currently we're out of resources to freeze current version and do it again from scratch.
