The specific event reflected in answer "a" would only be relevant to action taken with an other INPUT statement (as coded in your SAS program). So that action would need to either have or not have the appropriate "@" or "@@" (or neither) coded to determine how the current input record buffer condition is changed by SAS -- it would not happen automatically, as in the case a single "@" and iterating to the top of a DATA step execution.
An example of this being useful comes with files that have mixed record content resulting in different lengths in an irregular occurence pattern. Consider a data logger that has period output at hourly and daily intervals but may contain an event triggered record at any time of day and each of these record formats has a different length.
And then throw in a possibility of an incomplete record because of data transmission issues. If you read past the end of a record you can test for conditions to output diagnostics of approximately where the data file has problems and still capture the 'valid' data up to the break.
I'm sure that's not the only use but the one I remember dealing with that used this.