Yes, that’s still the mechanism. Not sure why the search isn’t working. That character may have meaning to the search engine. We will look into it.
The good news is that since it’s online, like the High Sierra fix, most fixes can be done server side.
For example, we have fixed several search terms that weren’t going to the right place.
And in case that strikes you as non-sensical, consider that MS Windows has always treated the & as a prefix character for the accelerator key for a button or menu title. That is, which letter is underlined as a visual indication Windows lets you use Alt+ that key to be the keyboard equivalent of clicking the item. Thus “&Save” would appear with the S underlined while Sa&ve would still look like the word Save but with the v underlined and you could use Alt+v to simulate clicking on it. You therefore needed && as an escape character so Windows knew you were not using & as the shortcut prefix.
Xojo presumably had to make macOS / Linux strip off the & character so that you could put your button titles and menu options to the same value cross-platform.
But if you never worked with Windows, needing to put in && may have always struck you as odd. It is not a Xojo bug; it is a feature. 
yes it always struck me as odd but I knew it was a windows thing, so i knew to always use ‘&&’ in GUI elements. But I think you and Geoff may be missing my original point: entering ‘&&’ when you want ‘&’ no longer works for radio btn captions:
<https://xojo.com/issue/68401>
Oh, I got that. I was just commenting on my supposition of WHY this was originally true. The fact it is not working the same now appears to be a bug. I was just trying to say there is a method to this madness of the need to use && when you want only &.