I realize the process as I work in software development.
Since the feature was already included in previous versions of Opera, it would be a simple matter of moving the existing code from one version to the other.

If you work in software development, you should realize that there's no such thing as a "simple matter of moving the existing code from one version to the other" when the basic engine framework and the API's on which your interface program is being overlaid are all different conceptually from what you've previously dealt with. The GUI's access points, rules, and interactions will be different across the two engines (Presto and Blink), so that code which ran under the Presto regime will not necessarily "simply move" to the Blink regime, let alone produce the same user interactions.

Consider the implications inherent in a user-interface "arrow-button" accessing a history file or memory block which is architected differently than previously, and which operates through a sandbox principle of separate processes for each tab. It's not necessarily "simple"... the only simplicity is in the initial concept of an arrow button providing such access, which is not the same thing as actually doing it.

Multiply the transference of this one "feature" or characteristic (an address box arrow accessing history) by the literal thousands of other "features", subtle or not, that exist and interact a certain way in a mature browser, and the result would be a major, hopelessly-complex "copying" effort. At a minimum, heavy triage of the transferred features would be necessitated by the sheer magnitude of the task. Instead, Opera elected to start from the ground up (build a completely new GUI) by first assessing what features it believed it needed to expend its efforts upon, whether we as users agree with its initial feature choices or not.