Are EF Core 3.1 ExecuteSqlRaw / ExecuteSqlRawAsync drop-in replacements for ExecuteSqlCommand / ExecuteSqlCommandAsync?

The rule is simple.

EF Core 2.x has 3 ExecuteSqlCommand overloads:

public static int ExecuteSqlCommand(this DatabaseFacade databaseFacade,
    RawSqlString sql, params object[] parameters); // 1
public static int ExecuteSqlCommand(this DatabaseFacade databaseFacade,
   RawSqlString sql, IEnumerable<object> parameters); // 2
public static int ExecuteSqlCommand(this DatabaseFacade databaseFacade,
    FormattableString sql); // 3

which in EF Core 3.x are mapped to

public static int ExecuteSqlRaw(this DatabaseFacade databaseFacade,
    string sql, params object[] parameters); // 1
public static int ExecuteSqlRaw(this DatabaseFacade databaseFacade,
    string sql, IEnumerable<object> parameters); // 2
public static int ExecuteSqlInterpolated(this DatabaseFacade databaseFacade,
    FormattableString sql); // 3

Functionally they are fully equivalent. Raw overloads supports the same placeholders and parameter values (both named and unnamed) as v2.x overloads #1 and #2. And Interpolated has the exact same behavior as the v2.x overload #3.

The reason for renaming the method and using different names for interpolated and non interpolated sql parameter is the C# compile time overload resolution for v2.x overloads #1 and #3. Sometimes it chooses interpolated when the intent was to use the other one, and vise versa. Having separate names makes intent clear.

You can read more about the reasoning in EF Core 3.0 Breaking Changes - FromSql, ExecuteSql, and ExecuteSqlAsync have been renamed.

The information about supported parameter placeholders,names and values can be found in Raw SQL queries - Passing parameters.

But to answer your concrete question, if the existing v2.x code is

context.Database.ExecuteSqlCommand("DELETE FROM Table WHERE ID = @p0", id);

then change it to ExecuteSqlRaw.

And if was

context.Database.ExecuteSqlCommand($"DELETE FROM Table WHERE ID = {id}");

then change it to ExecuteSqlInterpolated.

I didn't see where the docs ever define the contents of the userSuppliedSearchTerm variable or its type, and I'm struggling to see how it could be sensibly a nugget of SQL (string userSuppliedSearchTerm = "WHERE id = 123"; with baked in values? SQL Injection?) or a single primitive value (int userSuppliedSearchTerm = 123) so does it mean it's some kind of custom type that specifies the db column name and the value ? How does EFCore know which column from the table is to be queried? Does EFCore sort out the syntax error presented by the parentheses? Are the parentheses mandatory for EFCore to understand the query?

All nothing to do with EF Core

The docs have chosen to use a Table Valued Function dbo.SearchBlogs to demonstrate the use of raw SQL querying, so SELECT * FROM [dbo].[SearchBlogs]({0}) is legal SQL because SearchBlogs is a function, not a table/view - it just wasn't mentioned on the docs I linked