TypeConverters not working for Collections in @Que

I've an entity called Events which is defined as follows:

@Entity(tableName = "Events")
data class Event(@PrimaryKey val id: Long, val name: String, val venues: Set<String>, val rating: Int)

I've a pair of @TypeConverter methods for handling Set<String>:

@TypeConverter
fun fromStringToStringSet(str: String): Set<String> = str.split("<|>")

@TypeConverter
fun fromStringSetToString(set: Set<String>): String = set.joinToString("<|>")

In my Dao, I've a method annotated with @Query as follows:

@Query("UPDATE Events SET name = :name, venues = :venues WHERE id = :id")
fun updateAndRetainRating(id: Long, name: String, venues: Set<String>)

When I try to update an event with 2 venues, I get a runtime error telling me that the SQL couldn't be compiled. The generated SQL is:

UPDATE Events SET name = ?, venues = ?,? WHERE id = ?

This is obviously wrong. Looking into the generated code, Room is getting the size of Set<String> and adding the same number of ?s.

Why isn't my TypeConverter being used? I don't face this issue in other queries(@Insert and @Query(for SELECT)). Other TypeConverters are also working fine.

EDIT: The same issue also occurs if I use List<String> + TypeConverters instead of Set<String>.

Looking into the Room documentation, it appears that whenever we use a Collection in @Query, it bypasses TypeConverters and is straight away flattened.

For example, this:

@Query("SELECT * FROM Customers WHERE city IN (:cities)")
fun getCustomersInCities(cities: List<String>): Flowable<List<Customer>>

results in SELECT * FROM Customers WHERE city IN ('london', 'paris') if cities contains "london" and "paris".

Unfortunately, the following is also converted in a similar way:

@Query("UPDATE Customers SET phoneNumbers = :phoneNumbers WHERE id = :id")
fun updateCustomerPhoneNumbers(id: Long, phoneNumbers: List<String>)

The result is UPDATE Customers SET phoneNumbers = 1234567890, 9876543210 WHERE id = 23 if id is 23 and the phoneNumbers contains "1234567890" and "9876543210".

While this does make sense, it is really inconvenient and should be documented more clearly.