In short, you can enter spreadsheet formulas and in a later stage read them back, change them and re-enter them in the worksheet. 

The behaviour is controlled by an option structure options which has some fields ("flags") that can be set to TRUE or FALSE:

• options.formulas_as_text = 0 (the default) implies enter formulas as formulas and read back formula result
  options.formulas_as_text =1 (or any positive integer) means enter formulas as text strings and read them back as text strings.
  
  Be aware that there's no formula evaluator in JExcelAPI (JXL), OpenXLS, Odf Toolkit or jOpendocument. So if you create formulas in your spreadsheet using oct2xls or xlswrite with e.g., 'JXL', do not expect meaningful results when reading those files later on unless you first open them in LibreOffice, Excel or Apache POI and write them back to disk.
  
  
  While both Apache POI and JExcelAPI feature a formula validator, not all spreadsheet functions present in Excel have been implemented (yet).
  
  
  Worse, older Excel versions feature less functions than newer versions. So be wary as this may make for interesting confusion.
  
  
• options.strip_array = 1 (the default) instructs Octave to strip the output arrays resulting from reading a spreadsheet from empty outer rows and columns.
  
  
  options.strip_array = 0 will return the complete requested output range.
  
  
• options.convert_utf = 0 (the default) leave UTF-8 encoded text strings read from a spreadsheet untouched. Usually this works well as the Octave terminal usually knows how to display UTF-8 encoded strings - but note that Octve itself has limited support for processing multibyte-character strings. Windows 10 has proper support for UTF-8 in the cmd.exe terminal (used by Octave); but older Windows versions may need a conversion step:
  
  
  options.convert_utf = 1 currently invokes conversion functions utf82unicode.m (when reading from spreadsheet) or unicode2utf8 (when writing to spreadsheet). This can be useful when the strings in Octave that are intended to be written to spreadsheet file contain characters outside the range [32:127]; Excel and LibreOffice cannot process spreadsheets containing single characters outside that range.

COMPARISON OF INTERFACES & USAGE

The OCT or native Octave interface is completely under control of Octave (-Forge) developers. Currently it only offers support for .ods (relatively slow), .gnumeric (faster) and OOXML (relatively fast). An immense advantage is that no other external software is required.
However, all this comes at a price. Parsing xml trees into rectangular arrays is not quite straightforward and the other way round can be a real nightmare.

• OOXML (.xlx, .xlsm) files are merely g-zipped directory trees containing XML files. But that's the easy part. Internally all these XML files are cross-linked by various XML tags and especially the XML files that contain the data are extremely complicated. Octave reads those XML files using regular expressions; XML gurus will frown here but using regexps is extremely fast. OTOH it is also fragile as the order of XML tags and subnodes may differ from file to file. However, until now we've seen no problems.
  
  
• .ods files which are also (zipped) archives are different yet equally complicated. Unlike OOXML or gnumeric, .ods spreadsheet cells internally have no cell address tags so developers have to set up their own cell address bookkeeping; regular expressions are of little use here. While reading ODS is doable, writing implies checking whether cells already exist explicitly (in table:table-cells) or implicitly (in number-columns-repeated or number-rows-repeated nodes) or not at all yet in which case you'll need to add various types of parent nodes. Inserting new cells (“nodes”) or deleting nodes implies rebuilding possibly large parts of the tree in memory - nothing for the faint-of-heart. This is the reason that I/O to/from .ods with the OCT interface is quite slow.
  
  
• Gnumeric files are the easiest to read and write and like OOXML regular expressions work well and fast. A particular gotcha with gnumeric is that no cached data values are stored in the file. That means that Octave can't read formula results as hey just don't exist in the file; you really need Gnumeric itself for that. The reason is (as far as I could deduce from their support mailing lists) that the Gnumeric developers figured that files might be 30 % larger and they deemed that too much at the time.
  
  

So, after reading the above you might appreciate that the io package can also invoke pre-baked libraries that simply shield away the gory details. Most if not all open-source ones are Java based and therefore platform-independent. Read on:

ODF Toolkit (ODFDOM) is the one that gives the best (but slow) results at present for .ods. ODF Toolkit up til 0.7.5 did little to hide the gory details for the developers. Only with ODFToolkit (odfdom) 0.8.6, 0.8.7 and 0.8.8 things have been simplified for developers.
Unfortunately, with odftoolkit-0.6.0-incubating and odftoolkit-0.6.1-incubating (corresponding to odfdom-0.8.9 and 0.8.10) unresolved dependencies ("jenasin") have been introduced that break their functionality for Octave.

The jOpenDocument interface for .ods is more promising (and currently the fastest for not too big spreadsheets), as it does shield the XML tree details and presents to developers something which looks like a spreadsheet model. However, unfortunately the developers decided to shield essential methods by making them 'protected' (e.g. the vital getCellType). jOpenDocument does support writing. But OTOH many obvious methods are still lacking and formula support is absent (although announced for future version 1.4). And last (but not least) the jOpenDocument developers state that their development is primarily driven by requests from customers who pay for support. I do sympathize with this business model but for Octave needs this may hamper progress for a while. The last (and recommended) release was 1.4-rc2 from 2014.

Apache POI is based on the OpenOffice.org I/O Excel r/w routines. It is more versatile than JExcelAPI (below); while it doesn't support BIFF5 it does support BIFF8 (Excel 97 – 2003) and OOXML (Excel 2007).
It is slower than native JXL let alone Excel & COM but it features active formula evaluation, although still not *all* Excel functions have been implemented (a daunting task for the POI devs, as it is hard to keep up with MS here). I've made the relevant subfunction (xls2jpoi2oct) fall back to cached formula results (and yield a suitable warning) for non-implemented Excel functions while reading Excel files.

JExcelAPI (for .xls) is proven technology but switching between reading and writing is quite involved and memory-hungry when processing large spreadsheets. As the docs state, JExcelAPI is optimized for reading and it does do that well - but still slower than e.g., OpenXLS.
The fact that upon a switch from reading to writing the existing spreadsheet on disk is overwritten in place by a blank one and that you can only get the contents back wen writing out all of the changes is worrying - and any change after the first write() is lost as a next write() doesn't seem to work, worse yet, you may completely loose the spreadsheet in question. The first is by JExcelAPI design, the second is probably a bug (in octave-forge/Java or JExcelAPI ? I don't know). Adding data to existing spreadsheets does work, but IMO undue user confidence is needed.
JExcelAPI supports BIFF5 (only reading) and BIFF8 (Excel 95 and Excel 97-2003, respectively). Upon overwriting, BIFF5 spreadsheets are converted silently to BIFF8.
JexcelAPI, unlike ApachePOI, doesn't evaluate functions while reading but instead relies on cached results (i.e. results computed by Excel itself). Depending on Excel settings ("Automatic calculation" ON or OFF) this may or may not yield incorrect (or expected) results.

OpenXLS (an open source version of Extentech's commercial Java-xls product) is still a bit experimental. It seems to work faster than JExcelAPI, but it has other issues - i.e., processing of OOXML files is still unreliable. In addition OpenXLS scatters Extentech.tmp files here and there. For .xls (BIFF8) it works OK; in fact it is the fastest Java-based option for not too big .xls (BIFF8) file I/O.

UNO (invoking OpenOffice.org (OOo) or LibreOffice (LO) or clones behind the scenes, a la ActiveX) is experimental. It works FAST (i.e., once OOo itself is loaded and initialized which can take some time) and can process much larger spreadsheets than the other Java-based interfaces because the data are not entered in the JVM but in OOo's own memory.
A big stumbling block is that odsclose() on a UNO xls or ods struct will kill ALL OpenOffice.org invocations, also those that were not related to Octave! This is due to UNO-Java limitations. In fact this is the reason UNO is still considered experimental
The underlying issue is that after Octave started an Libreoffice invocation, Libreoffice must be closed for Octave to be able to exit; otherwise Octave will wait for LO to shut down before it can terminate itself. So Octave must kill LO to be able to terminate.
A way out hasn't been found yet and may even not exist.

Using Excel itself (through COM / ActiveX on Windows systems) is probably the most robust and versatile and especially FAST option. There's one gotcha: in case of some type of COM errors Excel will keep running invisibly and turn into a hidden "zombie" process; you can only end it through Task Manager.
A tiny problem is that one cannot find out easily through COM what file types are supported; xls, wks, wk1, xlsx, etc.; modern Excel versions can read .ods.
Another -obvious- limitation is that COM Excel access only works on Windows systems where Excel is installed.

All in all, of the three Java options I'd prefer Apache POI rather than OpenXLS or JexcelAPI. But the latter is indispensable for BIFF5 formats. Once UNO is stable it is to be preferred as it can read ALL file formats supported by OOo (viz. wk1, ods, xlsx, sxc, ...). If you need to process really large spreadsheets, UNO is by far the fastest option (behind COM on Windows systems), but for smaller spreadsheets you'll find that the other interfaces are more efficient.

The OCT interface (native Octave calls) is by far the fastest for OOXML, the only Octave option for gnumeric, but for ODS it is still slower than COM/ActiveX or UNO. OCT write support is available for OOXML, ODS 1.2 and gnumeric.

Some notes on the choice for Java:

1. It saves a LOT of development time to use ready-baked Java classes rather than developing your own routines and thus effectively reinvent the wheel.
2. A BIG advantage is that a Java-based solution is platform-independent ("portable").
3. The Java classes offer much more options than just reading and writing. Formatting, recalculation options, hiding/merging cell ranges, etc.
4. But Java is known to be not very conservative with resources, especially not when processing XML-based formats.

So Java is a compromise between portability and rapid development time versus capacity (and speed).

But IMO data sets larger than 5.10⁶ cells should not be kept in spreadsheets anyway. Better use real databases for such data sets.

A NOTE ON JAVA MEMORY USAGE

Java memory pool allocation size

The Java virtual machine (JVM), when initialized by octave, reserves one big chunk of your computer's RAM in which all Java classes and methods etc. are to be loaded: the java memory pool. It does this because Java has a very sophisticated "garbage collection" system. This part of memory is where the Java-based XLS/ODS octave routines live and keep their variables etc.

For transferring large pieces of information to and from spreadsheets you might hit the limits of this pool. E.g. to be able to handle I/O of an array of around 500,000 cells a memory pool size of 512 MB is needed.

The memory size can be increased by inserting a file called "java.opts" (without quotes) in the directory ./share/octave//java (where the script file javaclasspath.m is located; try "which javaclasspath" in an Octave terminal to get the proper location), containing just the following lines:

-Xms16m
-Xmx512m

(where 16 = initial size, 512 = maximum size (in this example), m stands for Megabyte. This maximum is system-dependent. E.g., I have a 1 GB setting).
For further details consult the Octave manual, "Java Interface", "FAQ", "How can I handle memory limitations?"

After processing a large chunk of spreadsheet information you might notice that octave's memory footprint does not shrink so it looks like Java's memory pool does not shrink back; but rest assured, the memory footprint is the allocated (reserved) memory size, not the actual used size. After the JVM has done its garbage collection, only the so-called "working set" of the memory allocation is really in use and that is a trimmed-down part of the memory allocation pool. On Windows systems it often suffices to minimize the octave terminal for a few seconds to get a more reasonable memory footprint.

TROUBLESHOOTING

Some hints for troubleshooting spreadsheet support are contained in this thread (for Excel): http://sourceforge.net/mailarchive/forum.php?thread_name=4C61B649.9090802%40hccnet.nl&forum_name=octave-dev dated August 10, 2010. Since that time a lot has changed.

As of April 2011 a special purpose setup file has been included in the io package (chk_spreadsheet_support.m) in which error checking and troubleshooting have been automated; it has evolved over time with core Octave itself.
When running it with the second input argument (debug level) set to 3 a lot of useful, hopefully self-explanatory diagnostic output will be printed to screen.

DEVELOPMENT

xlsopen / xlsclose and friends have been written so that adding other interfaces (Perl? ...?) should be very easily accomplished.
xlsopen.m merely needs two stanzas, xlsfinfo.m, xls2oct.m, oct2xls.m and getusedrange.m each need an additional elseif stanza, and xlsclose.m needs a small stanza for closing the pointer struct and writing to disk.

The real work lies in creating the relevant __<INTF>_spsh_open__.m & __<INTF>_spsh_close__.m, __<INTF>_spsh2oct__.m & __<INTF>_oct2spsh__.m, __<INTF>_spsh_info__.m, and __<INTF>_getusedrange__.m subfunction scripts in the ./private subdir, but that need not be really hard, depending on the interface support libraries' quality and documentation. The function scripts in the ./private subdir provide for ample examples.
Separating the file access functions and the actual reading/writing from/to the workbook in memory has made developer's life (I mean: my time developing this stuff) much easier.

Some other options for development (who?):

• Speeding up, especially Java worksheet/cell access. For cracks, not me. Presently each spreadheet cell is read or written individually; maybe there's a way to treat several cells at once. But the problem is undoubtedly how to translate possibly heterogeneous Java array structures into Octave heterogeneous cell arrays.
  Using ActiveX/COM an entire array is handed as an object from Excel to Octave and parsed in the Octave world; using OCT a worksheet is scanned using a regular expression for each data type in one fell swoop, and spreadsheets usually only have a limited number of data types (just double, text, logical, and some derived types).
• Automatic conversion of spreadsheet date/time values into Octave ones and vice versa (adding or subtracting 636960 in case of ActiveX/COM). But then again Excel's dates are 01-01-1900 based ("epoch"; Octave's epoch is 0-0-0000) and buggy (Excel thinks 1900 is a leap year), and I sometimes have to use dates from before 1900. Maybe as an option?
  The again each spreadsheet interface support SW has its own date representation and epoch which makes Matlab compatibility over all interfaces an elusive goal.
• Creating spreadsheet graphs (a significant enterprise to write from scratch).