[Fou-Lu]

I'm actually with you on this one; the $tbl_name doesn't necessarily indicate a structural fault. Especially if you want to write a system where a prefix may be added, you may choose to do something of the sorts (or assemble with {$prefix}actual_table_name for example). What IS a problem though is this: $mode = implode(",", $_POST['mode']); which is definitely a structural problem as you are putting a collection into a single field.
'sssssssss' represents the datatype of each input variable. These are all strings. Other options are 'i' for integers, 'd' for doubles, and 'b' for binary.
You can't use each of these directly. The problem is that mysqli_real_escape_string isn't sensitive to magic_quotes_gpc, and that mysqli_stmt is not sensitive to mysqli_real_escape_string. So lets take my data as \\mymachine\Fou-Lu's share\.
If magic_quotes_gpc is enabled, that automatically becomes \\\\mymachine\\Fou-Lu\'s share\\. With mysqli_real_escape_string, that now becomes \\\\\\\\mymachine\\\\Fou-Lu\\\'s share\\\\. Insert this using mysqli_query and the stored result is \\\\mymachine\\Fou-Lu\'s share\\. If you insert it using prepared statements, you get \\\\\\\\mymachine\\\\Fou-Lu\\\'s share\\\\. So all of these are corrupting your data.
With a regular query you need to escape it. But only once. With a prepared statement you do not escape it as it becomes a part of the input. The data and structure are different pieces of the puzzle, so you cannot corrupt the structure with providing it data such as I want.
So this is why you must:
1. Check for magic_quotes_gpc. If enabled, issue stripslashes to input (\\\\mymachine\\Fou-Lu\'s share\\ now becomes \\mymachine\Fou-Lu's share\);
2. If you are using prepared statement, no other steps are necessary (data is still: \\mymachine\Fou-Lu's share\).
3. If you are not using prepared statements, issue mysqli_real_escape_string to escape it (ie: data is now: \\\\mymachine\\Fou-Lu\'s share\\)

Does that make more sense?