First a terminology issue to try to eliminate confusion: "multiple document interface" (MDI) is a design where an application has a single “container” window within which the user can view multiple document windows (which each may be a form). This specifically refers to a design promoted by Microsoft for various productivity apps like early versions of MS Office. The alternative to MDI was a single document interface (SDI), where there is no container window -each document has it own top-level window. This implies that each document was also a separate process and thus SDI for multiple documents requires greater computer resources than MDI. However SDIs have better usability owing to their greater simplicity, so, with today’s powerful computers, MDI is obsolete and has been largely abandoned. MS Office partially moved away from it in 2002.
I don't think you mean to discuss the merits of "MDI."
To get at your question, I prefer to distinguish between “history navigation” versus “window navigation,” where the former is web-style and the latter is desktop style. Both support multiple “open” forms in a single application. The difference is how users navigate among the opened forms. History navigation has an implicit historic list of forms (or other pages) you can “move” back and forth through. Windows navigation has each form in a separate window so users “navigate” (if you want to call it that) by simply clicking on the opened window for the form they want.
Which is better? History navigation works best when users work superficially on many pages/forms, skimming for content, ignoring most of it, and only occasionally providing any input other than navigation. Window navigation works best when users work intensively on a few forms, providing substantial input (e.g., more than 30 seconds of work). In history navigation, forms effectively close themselves by simply being neglected, which is fine for superficial work, but a real drag if it means losing track of a lot of unsaved work.
For form-type work, window navigation has the following advantages over history navigation:
Simpler, faster, and more visual navigation for recently used pages. See the page you want and click on it. No going back or forward multiple times. No mentally tracking history.
“Paging” can be used for other purposes, such as showing multiple database records in the same window.
Exiting or logging out leaves no ambiguous pages apparently available for access. Log out with history navigation and the user can still back into the pages in the history chain, which is confusing at the least.
Input is preserved when the user navigates to another page. It obvious that a form in one window should not be cleared simply because the user has clicked on another window then returned focus to the original window. History navigation traditionally clears the form when the user navigates away from it and then returns, which is usually the wrong thing to do, but sometimes the right thing –there really isn’t a good way of dealing with it.
Assuming your window-navigation app is already performing well with users, don’t mess it up by trying to switch it into a history-navigation app. The main challenge will be getting users to not treat the opening of new windows as “pop-ups” to be blocked or closed. Another issue is the computer expertise of your users. Many low-end users don’t know how to handle multiple windows. They run every window maximized and seem unaware of the task bar. However these same users know how to use the back button on the browser.
I’ve more details of history navigation versus window navigation at Turn the Page. It also includes details of properly designing a windows-navigation web application.