BaDaBing

cd -- /home/TonySoprano /File_Rename_Project
...
    cd -- /mnt/c/Users/gabagool /dwhelper/"Courses"

Ba Da Boom!

chdir takes a single argument.

You can try to give it more. But it won't do you any good.

indent

           cd -- ...
               echo ...

I have no idea why those are at different indent levels. Please use the same indent level for commands in the same block. And try to stick to a multiple of 4 spaces.

Indenting the body of a for loop makes sense, but the rest of what you've written is quite hard to follow along with. You've not made it easy to recruit maintenance engineers to your team who will be able to effectively understand your code and make changes to it.

Error checking

When we use cd, we don't check whether it was successful. That may mean continuing to operate in the wrong directory. We should abort execution if it fails - that may be as simple as cd $dir || exit.

There are other commands in the script whose failure should cause early exit or be reflected in the script's own exit status. Don't assume that anything will be successful!

Layout

As mentioned in the @J_H answer, the indentation is inconsistent. Here is a more common way to indent the code:

#!/bin/bash

cd -- /home/TonySoprano /File_Rename_Project

IFS=$'\n' read -r -d '' -a wordlist < <( cat  Prepped.txt && printf '\0')

cd -- /mnt/c/Users/gabagool /dwhelper/"Courses"
echo  "Renaming files in "$PWD""

shopt -s nocaseglob
myFiles=(*.mp4)

IFS=$'\n' read -r -d '' -a my_array < <(printf "%s\n" "${myFiles[@]}"| sort -V  && printf '\0')

count=0 

for i in "${my_array[@]}";
do 
    mv -v "$i" "${wordlist[$count]}"
    ((count++))
done

I also removed the blank line inside the for loop since there is no real need for it.

Portability

When I try to run the code in my Linux OS, I see this kind of message for each cd line:

cd: too many arguments

Perhaps you also get those messages in your OS, but you might have missed them if they were mixed in with your other output.

Tools

The ShellCheck tool can be used to analyze your code for potential bugs and other style issues. When I run it, it is pretty clean, with only a few minor complaints. Good job there.

Naming

You used a few different naming styles for your variables. You should pick a style and stick to it. I prefer snake_case, where words are all lower-case and separated by an underscore:

word_list
my_files

You could give the variables more meaningful names as well. Using words like "my", "list" and "array" are too generic. For example, "wordlist" could be "file_names, "myFiles" could be "video_files", and "my_array" could be "sorted_files".

While i is a common iterator variable name, it is typically used for numbers. However, in your code it represents a file name. You could use file_name instead of i.

Just one thing I don't think others have pointed out yet:

printf "%s\n" "${myFiles[@]}"| sort -V

requires that your file names not contain newlines or you'd be sorting parts of file names so then there's no need to add surrounding code like this:

IFS=$'\n' read -r -d '' -a my_array < <(printf "%s\n" "${myFiles[@]}"| sort -V  && printf '\0')

when you could just use:

readarray -t my_array < <(printf "%s\n" "${myFiles[@]}"| sort -V)

I also strongly suspect that this:

IFS=$'\n' read -r -d '' -a wordlist < <( cat  Prepped.txt && printf '\0')

could similarly just be:

readarray -t wordlist < Prepped.txt

Btw, you don't actually need the myFiles array, you could just do printf '%s\n' *.mp4