Patch (base commit is current main, c75c752ff5) that seems to work in my local testing:

diff --git a/packages/codex/src/components/lookup/Lookup.vue b/packages/codex/src/components/lookup/Lookup.vue
index 1547b9cb9f..cf2ca1c3ca 100644
--- a/packages/codex/src/components/lookup/Lookup.vue
+++ b/packages/codex/src/components/lookup/Lookup.vue
@@ -33,6 +33,7 @@
 			:menu-items="menuItems"
 			v-bind="menuConfig"
 			@load-more="$emit( 'load-more' )"
+			@menu-item-click="onMenuItemClick"
 		>
 			<template #default="{ menuItem }">
 				<!--
@@ -311,6 +312,12 @@ export default defineComponent( {
 			menu.value.delegateKeyNavigation( e );
 		}
 
+		function onMenuItemClick( menuItem: MenuItem, $event: MouseEvent ) {
+			if ( $event.button === 0 && !$event.ctrlKey && !$event.metaKey ) {
+				$event.preventDefault();
+			}
+		}
+
 		// When a new value is selected, update the input value to match.
 		watch( selectedProp, ( newVal ) => {
 			// If there is a newVal, including an empty string...
@@ -372,7 +379,8 @@ export default defineComponent( {
 			otherAttrs,
 			onUpdateInput,
 			onInputFocus,
-			onKeydown
+			onKeydown,
+			onMenuItemClick
 		};
 	}
 } );
diff --git a/packages/codex/src/components/menu/Menu.vue b/packages/codex/src/components/menu/Menu.vue
index 8df87eba33..8947264bc3 100644
--- a/packages/codex/src/components/menu/Menu.vue
+++ b/packages/codex/src/components/menu/Menu.vue
@@ -43,7 +43,7 @@
 				:search-query="searchQuery"
 				@change="( menuState, setState ) =>
 					handleMenuItemChange( menuState, setState && menuItem )"
-				@click="$emit( 'menu-item-click', menuItem )"
+				@click="$emit( 'menu-item-click', menuItem, $event )"
 			>
 				<!--
 					@slot Display of an individual item in the menu
@@ -230,6 +230,7 @@ export default defineComponent( {
 		 * occasionally, a component might want to react specifically when a menu item is clicked.
 		 *
 		 * @property {MenuItemDataWithId} menuItem The menu item that was clicked
+		 * @property {MouseEvent} $event The native browser event
 		 */
 		'menu-item-click',
 		/**

This assumes that all Lookups should prevent the default click behavior; I’m not sure if that’s correct or whether it should be configurable.

This also assumes that keeping the menu items as native links is fine, which might not be the case judging by T237048. (But before we go ahead and reimplement native links with extra event handlers, someone™ should probably check whether T237048 is still relevant on more recent Android versions. The solution that was implemented for T237048 is not without its downsides, after all – it supports middle-click, but not right-click, for instance.)

@LucasWerkmeister I understand the request here but this seems like a bit of an edge case right now, so I'm hesitant to prioritize adding support for this. That being said, I wonder if exploring alternative UX solutions could solve your problem? What if you provided a different UI element somewhere that displayed a link to the currently selected data item? So the UX would be:

1. User selects an item from the Lookup dropdown.
2. A preview/link to the currently selected data item is available somewhere nearby (maybe beside or just below the Lookup).
3. A user can choose to open that link to make sure they selected the right item.

This is a slightly different workflow solution than you outlined but might still work just fine from a UX perspective (and would be more obvious for users who wouldn't know to middle-click or right-click).

To me that sounds like a pretty frustrating workflow :S in situations with multiple similar search results, after selecting the wrong result, I would have to:

• repeat the search
  • (probably changing the input field back to what my previous search was, because when I selected an item, the input was set ot to that item’s label)
• hope the search results come back in the same order(!), so that I still know which items I already tried and which ones are left
• select another item
• check if it’s the right one
• repeat until done

The point about the repeated searches yielding consistent results is my main problem with this – which isn’t an issue if I can directly open all the results of the same search.

In an effort to clean up our queue, I'm going to backlog this task for now to reflect that the design systems team acknowledges the request and use case but does not currently have capacity to take this on.