I always use a single numeric ID as the primary key unless I have a really good reason to do anything else, like if it is only a lookup table with 2 columns and then I make both columns primary. The ID is used internally by the database only and would never need to be changed, I do not use it as an identifier that anyone else would need to know. If you want to give your podcasts a number for people to identify them, make that another database field other than the ID. If you want a revision number, make that another database field. That way the ID will refer to a specific episode and revision. For as long as I've been doing this I haven't found a great use case for not just using an auto-increment primary key.
No, it's one of storage. A char field always stores the maximum number of characters that the field allows. A varchar only stores what is necessary but has a maximum length. See here for storage requirements. Note also that an int field always uses 4 bytes regardless of the length you gave it. If a number has a smaller range than use one of the smaller int types.
I agree, and that is what char fields do, they always store the maximum number of characters. You would only use a char field if the values will always be the same length, like for a GUID.
So why not utf8_unicode_ci? Do you want to allow people to have the same username with different capitalization or characters that look the same but are different unicode code points? That's what using utf8_bin would allow, it looks at binary data only and does not take into account case or whether two characters have the same meaning but are different code points.
It's just a question about data normalization. Databases have been around for decades, we have this figured out now. If there is a one-to-one relationship, that goes in a single table. If there is a one-to-many relationship, that's a parent and child table. If there is a many-to-many relationship, that's 2 tables with a third lookup table. The database is specifically designed to work with this kind of data, let it do its job. Don't increase the time required to insert, update, or select data because it's less complex for you. Data storage should be optimized for a computer, not a person. You can display it however you want it to show up, but make it easy for the database to do its job.
That should be an auto-increment primary key.
There's no reason to store a counter like that in a table, you can use SQL to get the count and then it's always going to be correct and you don't have to worry about updating it when things change. The way that's set up now, if you select the rows and order them by ID then it makes the count redundant, you don't need to store that data. I do use columns like that for display order if I want to allow the display order to be specified (as opposed to ordering by date or some other field), where it will be a sequential series, but if you're only storing the count there's no reason to do that.