With an explicit transaction, calls to SaveChangesare written to the database and as far as any queries you execute with that DbContext against the database, it will see them. What happens with queries outside of that transaction scope will depend on the isolation level of the database and the external query in question. For instance if your database is using a typical READ COMMITTED isolation level, while the transaction is open, external queries will be blocked until the transaction is committed or rolled back. If the database is using something like READ COMMITTED SNAPSHOT (often recommended for EF and other ORMs) then those third party queries will not be blocked, they will simply return data that excludes changes being made by the transaction.

For instance if I have a parent / child relationship and run the following:

using var context = new SoftDeleteDbContext();
using(var tx = context.Database.BeginTransaction());

var parent = context.Parents.Include(x=>x.Children).First(x => x.ParentId == 1);
var newChild = new Child("Dameon", 12, parent);
parent.Children.Add(newChild);
context.SaveChanges();

var data = context.Children.AsNoTracking().Where(x => x.ParentId == 1).ToList();

tx.Rollback(); // <-- Breakpoint Here

With a breakpoint on the Rollback, if I check the results of data I will see that my new child "Dameon" is returned. AsNoTracking() forces the query to the database. If you go to SSMS while this transaction is still running and run SELECT * FROM Children WHERE ParentId = 1 you would see all children except "Dameon" would be returned. He wouldn't appear in those results until the transaction is committed. After the rollback he won't appear in either queries. If you aren't using SNAPSHOT isolation then an SSMS query will be blocked by locks until the transaction is committed or rolled back.

If you want proof the row is in the database, you can use SELECT * FROM Children WHERE ParentId = 1 WITH (UNCOMMITTED) and "Dameon" appears.