That sounds like a lot of work! Why not Github issue tracker??
winget version of winbox 4 is out of dated.
https://winstall.app/apps/Mikrotik.Winbox.Beta
There is beta42 actually.
But what winget database knows as available is just the 4.0.beta.26.
After you install Winbox4, the app itself shows you the message to upgrade to 4.0beta42.
But the winget itself does not know about the existence of earlier version other than 4.0.beta.26.
The manifest file (in yaml) for Winget needs to be updated every version release and publicly publish (similar methodology as in RPMs and DEBs).
Mikrotik are not alone if overlooking winget when updating. Had to chase Devolutions twice to update Remote Desktop Manager.
It's not MikroTik that publishes it AFAIK. See winget-pkgs/manifests/m/Mikrotik/Winbox/Beta at master · microsoft/winget-pkgs · GitHub
Given MikroTik is seemingly aiming to keep old software out of the wild... leaving OS packaging to 3rd parties does not seem like the way to go. winget being just one example.
I’m not sure about how it happens.
If I remember correctly is something like “robots.txt” for search indexers…
You need to keep the yaml manifest on the major directory, and winget robot does the rest.
They could just add a symlink to latest, add put that into winget link.
And when a new version is available just change the symlink to that version.
Yes! I understand that if you specify the version, it will install the desired version.
But look at the screenshot below; even after installing the specified version, when upgrading, it reverts to an outdated version.
I don't know what's missing, or where it's missing. But something is definitely missing for the mechanism to work properly.
It's not expected that a regular user should have to specify the version to install the current version.
I believe it would be appropriate for Mikrotik itself to take on the role of making these adjustments in the winget-pkgs repository. Add this as a task within their CI/CD publishing.
I'm specifically talking about Winget, but this also applies to other package managers like Homebrew, MacPorts, Nix... or apt, yum, and YaST.
I think they have no interest in maintaining packages for all these package managers (you named them). I think this is perfectly normal. Or do you think that the maintainer of e.g. “curl” is package maintainer for every possible package manager that offers curl? I don’t think so. The usual way is: publish binary (or source when open source) somewhere. Mikrotik does publish their software binaries on their website.
Why? MikroTik offer the program on their website, and even offer an in-place-upgrade feature within the application. Why would they support that “winget” thing? When those people want to setup some superfluous software get thing, they are responsible for maintaining it.
It looks like winget does not even properly sort version numbers, and/or their repository offers the versions in an unsuitable order. Apparently winget requires the current version to be first so it is selected as a default install candidate, but that repository offers them in random order instead. Not a problem that MikroTik has caused.
Okay!
You're all right!
User-friendliness isn't that important.
Maybe the goal isn't to help average users become familiar with the tools and enjoy using them daily.
Maybe the goal is just to show how annoying and inconvenient the person pointing out the pain points is.
Maybe they should even remove the apps from the Apple Store and Play Store, and make the user install them manually.
I agree with @fischerdouglas in that MikroTik should publish WinBox in common app stores for Mac and Windows. Now whether winget is more common than Microsoft Store, IDK...
As mostly Mac user, if one wants a Mac-like experience, apps get installed via the App Store, period. And since Apple does static analysis of software on submission to App Store, ensures adherence to guidelines, and can recall apps if vulnerability is ever discovered - publishing WinBox has security benefits to users. So by not publishing in Mac App Store, we're lose some added security benefit of at least some audit on software outside of MikroTik.
On Linux, it is a bit more tricky and fragmented, so can see leaving it up to distro's to decide to include it. But there is a finite number of common classic package formats (.deb, .rpm) and newer Flatpack, Snap, and AppImage. And I just don't think it be that hard to automate their build to produce them along with the executable.
Nevertheless, it's wasted breath. I could dig up dozen of posts from @normis advising to not use any packaged WinBox solutions. And given MikroTik hasn't said "we plan to" at any point here, I don't think we'll see WinBox in "app stores" and/or "package managers" anytime soon.
But I know I'd feel better if I could download WinBox from Apple via the OS mechanisms, which include at least some vetting by Apple, and not via some website.
Mikrotik Android apps are published on Google Play only. There is not APK download on the website.
Not related to this topic, but it would be great, if they finally make apk downloadable on their website...
I have been maintaining Windows systems at work for over 25 years and I have never even once used “winget” during any of that…
It's new, and it's beautiful, and actually more functional than what was there bebofe.
Unlike winbox4
before there was nothing by Microsoft. “chocolatey” I used when I still used Windows, but it felt wrong. Same category of wrong as Homebrew on Mac.
There is also scoop PM for Windows (but is currently providing only WInbox 3). MacPorts FTW (for CLI tools) on Mac 
Personally I don’t have habit to install app over store or package manager if app itself has update check/install mechanism because usually new version will be available sooner over app update.