I tried the same as you did, and could not replicate the error. But encountered that Qgis sometimes uses another CRS than that stored in the prj file. So take care which CRS is applied to the loaded layers. I did some grids in both 29873 and user defined (red), and they match perfectly.
Here
http://www.georeference.org/forum/t96710 you find test road.zip data with the same prj file as yours, and that offsets to Google imagery only about 20 metres.
EDIT
There are some differences in the proj strings I and you are using:
my QGIS Master 29873:
+proj=omerc +lat_0=4 +lonc=115 +alpha=53.31582047222222 +k=0.99984 +x_0=590476.87 +y_0=442857.65 +gamma=53.13010236111111 +ellps=evrstSS +towgs84=-533.4,669.2,-52.5,0,0,4.28,9.4 +units=m +no_defs
LUKIP QGIS Lisboa 29873:
+proj=omerc +lat_0=4 +lonc=115 +alpha=53.31582047222222 +k=0.99984 +x_0=590476.87 +y_0=442857.65 +ellps=evrstSS +towgs84=-533.4,669.2,-52.5,0,0,4.28,9.4 +units=m +no_defs
SR 29873:
+proj=omerc +lat_0=4 +lonc=115 +alpha=53.31582047222222 +k=0.99984 +x_0=590476.87 +y_0=442857.65 +ellps=evrstSS +units=m +no_defs
Your proj string misses the gamma value. Thats the crazy thing about omerc: The projection axis is not a meridian (as most other merc projections), but with an angle to it. The coordinates are finally reprojected to have north up again. The SR string is even older, and misses the +towgs84 also.
The grid with my proj string in black and yours in red looks like this:
![Borneo grid comparison](https://i.stack.imgur.com/qNTJT.jpg)
You have taken the proj string from QGIS Lisboa, probably Windows standalone installer. There is a bug in that installer, which prevents QGIS from synchronizing with the built-in GDAL projection database. Installing in a path without blanks (that is not in C:\Programs (x86)\
solves that issue, or using OSGEO4W installer. Master is only available with the later one.
Earlier versions of GDAL had a different way of handling the omerc projection, which was found to be inaccurate, and replaced with the handling of the gamma value. But now you have a new version of GDAL built inside QGIS, but the old proj string in the not-updated CRS database.
You can modify the CRS database, called srs.db, with spatialite GUI (because its a sqlite database as well), or reinstall QGIS to have correct handling of EPSG:29873.
Figured out the problem.
Under properties, I had "Use project CRS" checked rather than "Prompt for CRS" when creating a new layer (http://i.imgur.com/wT0cGlR.png). So whenever I would upload the delimited file, it would automatically project to EPSG: 26914 rather than WGS84 / EPSG: 4326 that it should have been uploading in. So whenever I would change the Project CRS to WGS84 it would upload correctly because then it was giving the incoming layer the correct projection.
Thanks for everyone's help!
Best Answer
KML files use WGS84 LL by default, so yours should appear correctly positioned with respect to another dataset that you are confident is georeferenced (such a reference dataset is very useful when importing new data)
However if the DXF file has not been supplied with any description of the coordinate system used then you have a few options.
Ideally you should be able to go back to the supplier and get the coordinate system details from them. They may have used a standard coordinate system, or as is often the case with DXF files, the coordinates may be a local system defined for surveying a construction site.
A useful first pass is to load the data in an unknown CRS (your DXF file) into QGIS with OFT disabled, and look at the magnitude of the coordinates reported for the data - if it is less than 180 in the X and 90 in the Y then it is likely that the data is in a geographic (Lat / Lon) system. If the coordinates' magnitude is larger then they are probably in a projected system. If the latter, check where the 0,0 coordinate position is, if it is close to the bottom left of the data then that might indicate a local coordinate system.