Two tables with two different charsets
Each column of each table of each database can have a different CHARACTER SET and COLLATION.  There is no downside unless you JOIN on a column that has different charset and/or collation.

Ascii (7-bit stuff) is a subset of latin1 and of utf8mb4.  As such, the encoding is identical, so no space difference will be seen for purely ascii text.

However, there are a few hiccups when you declare unnecessarily large strings, especially with wider character sets.  Probably you won't hit any hiccups.  Please provide SHOW CREATE TABLE for a review of likely cases.

The client must declare what charset it is using, so UTF-8 is what you would need there.  In that case, any non-utf8mb4 columns would be automatically converted when going between client and server.

More

When storing into VARCHAR(...) CHARACTER SET utf8mb4, there is a 1-byte or 2-byte length overhead, plus


"abc" (ascii) will take 3 bytes - each ascii character takes 1 byte,
"ÛØÎ" will take 6 bytes - most European chars take 1- or 2-bytes,
"José" will take 5 bytes - the "é" takes 2 bytes,
"" (Emoji) will take 12 bytes; each Emoji is 3 or 4 bytes.  Ditto for Chinese.
"$€" (currency symbols) will take 4 bytes -- 1 for "$" plus 3 for Euro.


With CHARACTER SET latin1:


"abc", "ÛØÎ", "José", "$€" can be correctly stored in latin1, using 3,3,4,2 bytes, respectively.
Emoji, all Asian languages, Greek, Cyrillic, and others cannot be represented in latin1.  Garbage ensues.  The particular garbage depends on the various settings; this Q&amp;A lists common garblings.


For clear sailing:


The column must be declared (explicitly or implicitly) with a CHARACTER SET that can hold the characters.  (English will work with any character set, but Emoji will work only with utf8mb4.)
The connection parameters (or SET NAMES) must correctly say what encoding is used in the client.
There must be a mapping between the two charsets.  (English always maps.  (Western Europe can map among latin1, utf8, utf8mb4, but not much else.)