Scheduled Apex – Does It Use Synchronous or Asynchronous Governor Limits?

First of all, the exception thrown by hitting a limit, System.LimitException is uncatchable and means that your script will be killed, even if it happens inside a try/catch block. There is a class, Limits, that contains a number of static methods that allow you to check your governor limit consumption, see: http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_methods_system_limits.htm

With that said, your example of @future calls per day is one of the limits that simultaneously is and isn't a governor limit as I believe it throws a System.AsyncException instead which is catchable. is not catchable, and kills your script as a LimitException would.

Salesforce provides a decent explanation of transactions:

What is an Apex Transaction?

An Apex transaction represents a set of operations that are executed as a single unit. All DML operations in a transaction either complete successfully, or if an error occurs in one operation, the entire transaction is rolled back and no data is committed to the database. The boundary of a transaction can be a trigger, a class method, an anonymous block of code, a Visualforce page, or a custom Web service method.

All operations that occur inside the transaction boundary represent a single unit of operations. This also applies for calls that are made from the transaction boundary to external code, such as classes or triggers that get fired as a result of the code running in the transaction boundary. For example, consider the following chain of operations: a custom Apex Web service method causes a trigger to fire, which in turn calls a method in a class. In this case, all changes are committed to the database only after all operations in the transaction finish executing and don’t cause any errors. If an error occurs in any of the intermediate steps, all database changes are rolled back and the transaction isn’t committed.

So, to answer your original question, that will be treated as two transactions. Clicking a button to fire off a single call works as one transaction that will complete. When you click it again, it will be another transaction.