I was working on exactly this in my own repo and have a good chunk of the foundational work done and tested. If I move that work here it would benefit from the integrated CI and test resources of this project as well as get broader testing, feedback and coding participation.

I have been playing with retrofitting the current "download.sh" with the automatic version detection code and was asked to make some other changes - it is evident it would be a major refactor to work in all of the below.

Here is my thinking:

Fresh Code / New Name, because:

• I can develop it in parallel without disturbing anyone who has dependencies on download.ps1 (could eventually retire it after some depreciation notices)
• the existing code is pretty organic with regard to what nuances of the target it can detect, I would like to start fresh with better code for detecting the full range of possible install targets, versions, revisions, etc and remove any artificial limiting (e.g. current installer does CentOS only, yet it applies to all redhat). Also giving notices to unsupported OSes - so the existing code seems to be CentOS / Rhel 7 specific - but if I run on 6 against the repo I believe I'll just get nothing happening rather than an "unsupported" message.
• "download" doesn't really describe what is going on and especially if including the development environment as mentioned below.

New Features:

• always assume a full automated, non-interactive install by default (optional switches that cause interactivity (e.g. loading a VS code test script) are ok
• autodetect current version from git tagging - no need for manual updates with version releases.
• always configure repos where they exist for a given target and update the script whenever a new repo is added for a given target
• publish oneliners for pulling it directly onto a machine as comments in the top of the script
• actively maintain the code to exclude known non-working targets or include known to work OS targets (for instance when it becomes known that a package works on an older version of OSX that powershell was compiled for). Maybe requires a switch like "-overridestrictversiontargeting" ?
• command line switch to use .appimage instead of native package.
• [not committed to this one yet] - for targets that don't have a repo, allow re-running to update to the latest (but only if underlying packages are already engineered to be installed right on top of previous versions)
• segment platform installs into their own script to:
  • keep the code cleaner
  • allow grabbing a specific installer if autodetection is not required
• for any additional script retrievals, favor a local copy if one exists, otherwise pull it from the repo

Full Dev Environment Feature (optional switch "-includedevenvironment" or some such)

• installs visual studio code (again using repos whenever possible)
• installs ms-vscode.PowerShell extension into vs code
• (optional) loads a powershell into vs code and instructs user to press F5 to test running code in IDE (can be disabled by switch)

The reason I think the Dev Environment feature is relevant is that it could help drive adoption if people can run one script and be developing in a full PowerShell IDE to try it out. If they end up wanting to do mass distribution, they just drop the dev environment switch to hit their production targets. Some may even want the IDE on every target just like ISE is on every Windows machine. Especially if they are Windows admins moving to manage Linux with their tried and true PowerShell skills.

I have most of these ideas scaffolded and tested on Ubuntu and CentOS.