One of the challenges with managing a complex wiki or ticket system is avoiding the creation of duplicates, whether for inexperienced or even for seasoned users, especially once you start having multiple hundreds or thousands of items.
The main way to solve this is by providing a UI and UX that enforces duplicates detection. You shouldn't rely on users to always keep a secondary tab open and be patient enough to manually run a search everytime they want to create something. When the user starts creating a new wiki page (choosing its name etc.), or types into the task/item's title/summary field(s), or even possibly in the description (optionally), Tiki should detect potential duplicates with other items and present those to the user live, if it's reasonably confident with the results (especially with manticore search functionality).
From a UX/design perspective, other than Tiki Tracker's "Related" search field in the UI, one of the best examples/implementations I've seen is in recent versions of Bugzilla, where they force you to run a search at the start of the bug reporting process (it would be nicer if it was a live search rather than needing to click the "Find similar issues" button, but that's probably for performance/speed reasons).
Discourse also does it automatically when you create a new forum thread.
See attached screenshots.
Ideally, to make it entirely frictionless, Tiki should do this search live as the user types, and show the results below the related field (and/or in a popup/popover widget). Performance caveat of live searches: item81602
As you can see, this goes way beyond just "autocompletion", this is a coherent UI in support of preventing duplicates and enforcing the reuse of existing information, which is coherent with the concepts of "convergence", "don't repeat yourself / DRY", and "accidental collisions" as part of the Wiki Way.