As the publisher of url_forwarding I would definately like to have this functionality in the core.
My extension is using the first hook available, so not everything is fully running, unlike the old redirect functionality of realURL, which was at the end of the process (was triggered just before “page not found”). It is used on the website of the Technical University of Eindhoven, which is quite large. For them it is working out very well. One of their websites almost has 1000 redirects, mostly used as kind of shortcut.
Redirect functionality should only be there for redirecting, like using some kind of shortcuts. The handling of modified pages should be done by the routing/path handling, like realURL (already does) or core solution. Old URL’s should be handled as much automated as can be. An editor should not be bothered much when renaming or moving a page.
True, it should be extensible. url_forwarding also has, for instance, the possibility to replace a part of a path. But this is added to handle renamed or moved pages which have a lot of subpages. Like I said, this should be handled by the path handling/routing automatically, if possible.
As Mathias Brodola is already mentioning, this is not only for marketing, but covers much more.
Sometimes it is really helpful. Since I’m using dedicated records for the redirects, you don’t have a clear overview in the page tree which page contains a redirect. With this option you can make this visible. Maybe have the possibility to turn it on/off for certain backend user groups?
Somehow this should also be incorporated/linked in SEO tools, like Yoast SEO for instance for the page slug.
I am still uncertain if dedicated records are needed for page redirects, or should be handled directly in the page properties.
A proper BE module is needed to maintain the redirects.