What does it mean to open an "Anaconda" prompt distinct from command prompt and how to?

The Anaconda command prompt looks like normal windows command prompt and its start menu shortcut traces back to the cmd.exe file on windows in the C:\Windows\System32 directory, so I know it is just an instance of the command prompt with certain other characteristics or features. I am curious as to what all these other aspects are.

When I click on properties of the "Anaconda Prompt" shortcut, the target is "%windir%\System32\cmd.exe" /K" C:\ProgramData\Anaconda3\Scripts\activate.bat C:\ProgramData\Anaconda3 so it has some extra arguments. In those arguments is the difference between opening a vanilla command prompt and an Anaconda.

Breaking down these commands, the /k option appears to be described here and here to mean run the command and return to the prompt, although those references refer to a lower case /k.

The next argument points to a bat file to activate an Anaconda script. Then it passes a path to a directory called "Anaconda3". I am fairly certain the path it passes as the final arg means it wants this path to be accessible as if it were in the user or system path environmental variable. Python.exe (Python 3) is in this directory, as well as a _conda.exe and an important Scripts folder, so if we don't have our python in the system or user path, this is how it is found, I am fairly certain.

Back to the .bat file, this does a lot of things. I always though bats were binaries, because of how they acted on the system, but they're really just like Bash Scripts for Windows. They are human readable and mine is as follows:

@set "_args1=%1"
@set _args1_first=%_args1:~0,1%
@set _args1_last=%_args1:~-1%
@set _args1_first=%_args1_first:"=+%
@set _args1_last=%_args1_last:"=+%
@set _args1=

@if "%_args1_first%"=="+" if NOT "%_args1_last%"=="+" (
    @CALL "%~dp0..\condabin\conda.bat" activate
    @GOTO :End
)

@REM This may work if there are spaces in anything in %*
@CALL "%~dp0..\condabin\conda.bat" activate %*

:End
@set _args1_first=
@set _args1_last=

This .bat calls another .bat, "conda.bat", in a nearby directory with it's own code:

@IF NOT DEFINED _CE_CONDA (
  @SET _CE_M=
  @SET "CONDA_EXE=%~dp0..\Scripts\conda.exe"
)
@IF [%1]==[activate]   "%~dp0_conda_activate" %*
@IF [%1]==[deactivate] "%~dp0_conda_activate" %*

@SETLOCAL EnableDelayedExpansion
@IF DEFINED _CE_CONDA (
  @REM when _CE_CONDA is defined, we're in develop mode.  CONDA_EXE is actually python.exe in the root of the dev env.
  FOR %%A IN ("%CONDA_EXE%") DO @SET _sysp=%%~dpA
) ELSE (
  @REM This is the standard user case.  This script is run in root\condabin.
  FOR %%A IN ("%~dp0.") DO @SET _sysp=%%~dpA
  IF NOT EXIST "!_sysp!\Scripts\conda.exe" @SET "_sysp=!_sysp!..\"
)
@SET _sysp=!_sysp:~0,-1!
@SET PATH=!_sysp!;!_sysp!\Library\mingw-w64\bin;!_sysp!\Library\usr\bin;!_sysp!\Library\bin;!_sysp!\Scripts;!_sysp!\bin;%PATH%
@SET CONDA_EXES="%CONDA_EXE%" %_CE_M% %_CE_CONDA%
@CALL %CONDA_EXES% %*
@ENDLOCAL

@IF %errorlevel% NEQ 0 EXIT /B %errorlevel%

@IF [%1]==[install]   "%~dp0_conda_activate" reactivate
@IF [%1]==[update]    "%~dp0_conda_activate" reactivate
@IF [%1]==[upgrade]   "%~dp0_conda_activate" reactivate
@IF [%1]==[remove]    "%~dp0_conda_activate" reactivate
@IF [%1]==[uninstall] "%~dp0_conda_activate" reactivate

@EXIT /B %errorlevel%

As I expected, when I called the activate.bat file in an ordinary (admin) command prompt, it turned into an Anaconda prompt with the "(base)" prefix before my current path you get when you click the startup shortcut. (base) C:\Users\User>. Interestingly, doing this only seems to work in the regular command prompt, not Git Bash, not WSL, not even Powershell, though there is a separate Powershell launcher that works. In its properties, it has the target: %windir%\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy ByPass -NoExit -Command "& 'C:\ProgramData\Anaconda3\shell\condabin\conda-hook.ps1' ; conda activate 'C:\ProgramData\Anaconda3' "
And if you run the ps1 file (a powershell like script), it has the same effect of putting you into the conda environment, because you can run the 'conda' command and help instructions appear.

Here is the ps1 code.

$Env:CONDA_EXE = "C:/ProgramData/Anaconda3\Scripts\conda.exe"
$Env:_CE_M = ""
$Env:_CE_CONDA = ""
$Env:_CONDA_ROOT = "C:/ProgramData/Anaconda3"
$Env:_CONDA_EXE = "C:/ProgramData/Anaconda3\Scripts\conda.exe"

Import-Module "$Env:_CONDA_ROOT\shell\condabin\Conda.psm1"
Add-CondaEnvironmentToPrompt

Anyway that's just kind of the background context, which I learned in the last few hour researching, because I wanted to do my homework. I wanted and want to know is what Conda is doing in Windows when you open the Command Prompt through Anaconda. I'm pretty certain it is doing two main things: setting the path to include the C:\ProgramData\Anaconda3 directory, for the session, and activating it's base environment or any other virtual environment you tell it to launch that you may have created through it at some point, but does it do anything else of note?

I ask this not just because I am curious about what's really going on (I am), but I was also hoping to work with Conda in Git Bash and WSL, terminals I really like. I can currently use Conda's Python with them (the only Python on my machine) as it seems to exist independent of the program that installed it and manages packages for it, but I was specifically hoping to use the all the Conda environment management tools inside Git Bash or WSL. After thinking about it, I now don't believe this is possible. From a naive user perspective, one sort of assumes they can run any program anywhere, and that makes sense or would have made sense before we had sub-systems and systems within systems, but from a more aware point of view, Anaconda was installed for Windows and inside the C:\ProgramData\Anaconda3 directory are .exe and .bat files, not Linux/WSL compatible binaries and .sh or .bash files. It's like trying to run Windows_OS>Linux subsystem>Windows_file_again, but it doesn't work like that. WSL and Git Bash don't even have the same path structure somehow. Am I right in my thinking so far?

I enjoy Git Bash and WSL more than Powershell or cmd and I use them a lot for GCC and git. I do most of my coding in VS Code and launch these terminals there. I suppose at best I could install conda for git bash or wsl if such a thing existed, but even then it might not be able to talk to my main Conda or share environments. Otherwise I could either trying using venv for an environment, as that appears to work in these shells through python, or just use the normal command prompt to do everything if I really want to use Conda.

Am I right in my assessments?

Thanks for sticking with me! To get good at something, you have to get to the point where it's all plainly obvious, otherwise you run the risk of being lost and confused at a time you least want to be.

Edit: Now that I'm back at it, I rediscovered my original hurdle: the fact couldn't use Conda's command prompt straight from the VS Code or how to activate it once I booted the normal command prompt. Now I know about the .bat startup script at least and could in theory activate it that way each time, but it's kind of awkward, or I could launch a prompt externally and navigate to my working directory, but that's clumsy too. I forgot that this was my first blocker, and on a related note I had similar issues with x64 Native Tools (a Visual Studio based command prompt). I wondered what that was as well, why it looked like an independent terminal but I couldn't launch it in VS Code.